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GLOSSARY 



AADC - All Applications Digital Computer 
ADD - Alphanumeric Display Device 
ADP - Automatic Data Processing 

APE - Advanced Production Engineering Model - a militarized 

prototype 
CDC - control Data corporation 
CMTU - Cartridge Magnetic Tape Onit 
CNM - Chief of Naval Material 
CNO - Chief of Naval Operations 

COMNAVELEX - Commander, Naval Electronic Systems Command 

CVTSC - Carrier Tactical Systems Center 

DCAS - Defense Contract Administration Service 

DEC - Digital Equipment Corporation 

DMA - Direct Memory Access 

DPS - Data Processing System 

DRG - Design Review Group 

ESA - Externally Specified Addressing 

FCDSSA - Fleet Combat Direction Systems Software Activity 
FDM - Functional Demonstration Model - a non-militarized 

prototype 
GFCS - Gun Fire Control System 
GFE - Government Furnished Equipment 
IBM - International Business Machines Corporation 
ILS - Integrated Logistics Support 
I/O - Input/Output 
IOC - Input/Output Controller 

ISADC - Interim Standard Airborne Digital Computer 
LSI - Large Scale Integration 

MATHPAC - Plug-in module of floating-point, trigonometric 
and hyperbolic functions implemented in microcode 
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MICROGRO WTH - Plug-in module of user specified microprograms 
MOS - Metal Oxide Semiconductor 
MSI - Medium Scale Integration 
MTBF - Mean Time Between Failures 
MTTR - Mean Time To Repair 

NAFI - Naval Avionics Facility, Indianapolis 

NAVAIR - Naval Air Systems Command 

NAVELEX - Naval Electronic Systems Command 

NAVMACS - Naval Message Address Communications System 

NAVMAT - Naval Material Command 

NAVORD - Naval Ordnance Systems Command - combined with 

NAVSHIPS to form NAVSEA 
NAVSEA - Naval Sea Systems Command - formed by combining 

NAVORD and NAVSHIPS 
NAVSEC - Naval Systems Engineering Center 

NAVSHIPS - Naval Ships Systems Command - combined with 

NAVORD to form NAVSEA 
NELC - Naval Electronics Laboratory Center 
NESEC - Naval Electronic Systems Engineering Center 
NTDS - Naval Tactical Data System 
OMB - Office of Management and Budget 
O&MN - Operations and Maintenance Navy Appropriation 
OPEVAL - Operational Evaluation 
OSD - Office of the Secretary of Defense 
QA - Quality Assurance 
RAM - Random Access Memory 

RDT&EN - Research, Development, Test and Evaluation Navy 
Appropriation 

REWSON - Reconnaissance Electronic Warfare Systems Office 
Navy 

RFP - Reguest for Proposals 

ROM - Read-Only-Memory 

SECDEF - Secretary of Defense 

SSA - Source Selection Authority 

SSAC - Source Selection Advisory Council 

SSEB - Source Selection Evaluation Board 
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TADSO - Tactical Digital Systems Office of the Naval 

Material Command 
TADSTAND - Tactical Digital Standard 
TALOS - long-range, surface-to-air missile 
TARTAR - short-range, surface-to-air missile 
TECHEVAL - Technical Evaluation 

TERRIER - intermediate-range, surface-to-air missile 
TTL - Transistor-Transistor Logic 

ONIVAC - ONIVAC Defense Systems Division of Sperry-Rand 

Corporation 
HCS - Writable Control Store 
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I. INTRODUCTION 



A. THESIS OBJECTIVE 



In 1972 the Navy began procurement of a small digital 
computer which was to be a standard minicomputer for 
tactical system applications. That standard minicomputer 
was later designated the AN/UYK-20(Y) Data Processing 
System. 



The acquisition strategy employed and the resulting 

events of the first three years of production caused great 

concern among project managers who were required to use the 
standard minicomputer. 



At least one user project manager believed that an 
objective look at the standard minicomputer acquisition was 
necessary to prevent recurrence of those events which 
adversely impacted on the development of tactical systems. 



It is the objective of this thesis to examine the 
standard minicomputer acquisition process, to evaluate the 
system in light of user needs and 1972 state-of-the-art, to 
identify those events which contributed to the adverse 
impact of the standard minicomputer on development efforts, 
and to offer some recommendations for future acquisitions of 
standard tactical digital processors. 



B. METHODOLOGY 
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In order to obtain information about minicomputers in 
general and the AN/UYK-20(V) Data Processing System in 
particular, a literature search was conducted. Pertinent 
references are listed at the end of the thesis. 

To obtain a complete and objective picture of the 
acquisition process it was then necessary to contact 
personnel at all levels in user project organizations and 
also personnel in the standard minicomputer project 
organization. The following types of activities were 
contacted to obtain information: 

* Navy field activities - responsible for assembly, 
checkout, delivery and maintenance of tactical 
systems hardware and software. 

* Navy laboratories - responsible for certain aspects 
of tactical system development and testing. 

* Private contractors - responsible for hardware and 
software development of tactical systems under 
contract to Navy project offices. 

* Navy project offices - responsible for management of 
the acquisition of tactical systems utilizing UYK-20 
as a system component. 

Additional information was obtained by attending two 
AN/UYK-20 User's Group meetings. A minimal amount of 
laboratory experience was gained on the UYK-20 itself. 
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II. IDENTIFICATION OF THE NEED FOR A STANDARD MI NI COMPUTER 



The 1960*s saw the first successful employment of a 
general purpose digital computer in a shipboard tactical 
system. This event precipitated the introduction of a large 
number of shipboard computers into the Navy inventory 
manufactured by several different companies with slightly 
different capabilities. Some of these computers are "listed 
below. Others existed, particularly in avionics 
applications. 



Computer 


Cognizant 
Syscom 


Application 


MK 74 


NAVORD 


TARTAR Missile Syst 


MK 76 


NAVORD 


TERRIER Missile Sys 


HK 77 


NAVORD 


TALOS Missile Syste 


MK 86 


NAVORD 


Gun Fire Control Sy 


AN/USQ-17 


NAVSEC 


NTDS 


AN/USQ-20 


NAVSEC 


NTDS 


CP642 


NAVSEC 


NTDS 


CP642A 


NAVSEC 


NTDS 


CP642B 


NAVSEC 


NTDS 


AN/UYK-7 


NAVSEC 


NTDS 


AN/SYA-12 


NAFI 


Communications 


AN/0YK-15(V) 


NAVSEC 


General Purpose 


CP890 


NAVSHIPS 


Navigation 


AN/OYK-12 (V) 


NAVSHIPS 


General Purpose 



This proliferation of tactical processors created the 
following types of problems: 



* Small and uneconomical procurement programs. 
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* Untenable material and logistics support posture. 

* Increased scope of personnel training requirements. 

* System interface and integration problems. 

* Software incompatibility. 

* Proliferation of support software. 

Recognition of these problems prompted the Chief of 
Naval Operations (CNO) to direct the Chief of Naval Material 
(CNM) to develop a standard general purpose computer for 
shipboard and shore applications. In August 1971, CNM 
created the Tactical Digital Systems Office (TADSO) 
(MAT-09Y) to carryout this directive. Figure 1 shows the 
position of TADSO in the NAVMAT organization as of January 
1975. The chart illustrates that the Director of TADSO was 
in an influential postition, reporting directly to the Vice 
Chief of Naval Material. HAT-09Y has traditionally been a 
Sear Admiral. 

CNM, by reference 1 , described the scope of TADSO 
efforts: 

"(1) Inter-and intra- platform compatibility of all 
tactical digital systems and equipment. 

(2) Standardization of tactical digital equipment and 
associated software. 

(3) Configuration and interface management of tactical 
digital equipment and software." 

On 3 November 1971 TADSO published its first Tactical 
Digital Standard (TADSTAND 1) [Bef. 2] which established the 
AN/UYK-7 processor as the standard computer for shipboard 
applications and the CMS-2 high-level language as the 
standard high-level language to be employed in the 
production of operational programs for tactical data 
systems. TADSTAND 1 also provided that a request for 
deviation from these standards could be initiated to TADSO 
if it was thought to be in the best interests of the Navy to 
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use either another Navy computer or a computer not presently 
in the Navy inventory. 

In response to TADSIAND 1 some requests to deviate from 
the OYK-7 standard were received. The most significant 
justification given was that the OYK-7 was too large and 
expensive ($720,000 average cost) for the intended 
application. (See App. A for a description of the OYK-7 
computer.) Out of this identified need for a smaller 
computer grew the AN/UYK-20 (V) Data Processing System (DPS) , 
the Navy standard minicomputer. 

It is the purpose of this chapter to establish the 
meaning and implications of the terms "minicomputer" and 
"standard", to identify the capabilities needed within the 
Navy in a standard minicomputer system, and to establish 
whether or not these capabilities could be met by a small 
computer existing in the Navy inventory in 1972. 



A. DEFINITION OF A MINICOMPUTER 

Commercially available computers in 1972 formed almost a 
continuous spectrum in size, power and capabilities. 
Naturally, it is is difficult to separate the minicomputer 
from larger or smaller types. 

The possibility of a small computer with useful 
capabilities and memory capacity grew with the, development 
of hybrid and integrated circuits in the mid-1960 1 s. In 
1970 medium- and large-scale integration was introduced, 
allowing even more capability to be designed into a small 
package. At the same time these advancements were reducing 
hardware costs at the rate of an order of magnitude per 
decade. The advent of mini- peri pherals specifically 
designed for use with minicomputers was the final addition 
to complete, low-cost mini-systems. At that time, as was 
still true in 1976, software was the predominant cost of 
such systems. 
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C. Weitzman [Ref. 11] defined the minicomputer as an 8* 
to 18- bit word size machine with memory size from 1K to 32K 
words. Costs range from $4,000 to $100,000. The 
minicomputer is generally catagorized as having limited 
accuracy, low speed for double-precision arithmetic 
operations and no floating-point hardware. By 1972, 
however, many minicomputers had multiple Input/Output (I/O) 
access features and microprogrammable central processors 
allowing extensive instruction repertoires with firmware 
implementation of floating-point and special mathmatical 
functions. A more detailed discussion of the minicomputer 
technology of the early 1970* s may be found in Chapter IV, 
section B. 



B. DEFINITION AND IMPLICATIONS OF A "STANDARD" 

A "standard" could be defined as a specific entity which 
will be used in every application where an entity of that 
general description is required. 

The contents of the several TADSTANDS published by TADSO 
imply the following Navy policy concerning a "standard": 

The entity identified as a "standard" will be used in 
all developing and future tactical digital system 
applications except where deviation is specifically 
provided for, requested and approved. 

References 3 through 9 are the standards promulgated by 
TADSO as of May 1976. The impact of such standards in user 
system design will be discussed in Chapt. IV. The 
implications of establishing standards are summarized in the 
following paragraphs- 
Standardization allows realization of the economies of 
large scale production. For example, as of May 1976, 824 
AN/OYK-20 Data Processing Systems had been ordered and 637 
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units delivered. At that time there were 107 programs using 
the system. [Fig. 2 ] At the outset of the UYK-20 acquisition 
the estimated production run was in excess of 4500 units. 
This volume is over an order of magnitude greater than any 
one program would require in an independent processor 
acquisition. Clearly, the economies of scale would be 
realized with such a program. Although it is impossible to 
quantify the actual savings realized by using UYK-20 in any 
particular project, the economies of scale are demonstrated 
in the volume order prices for an AN/UYK-20 (V) DPS basic 
configuration in fiscal year 1974: 

Quantity - 50 at $25,966 each 
Quantity - 100 at $24,735 each 
Quantity - 150 at $24,324 each 

It is also interesting to note that the Fiscal Year (FY) 
1976 order price for a similar configuration is about 
$25,000 each, approximately the same as the FY 74 price 
despite inflation. 

Standardization realizes cost savings in material 
support. One project manager estimated that the cost of 
introducing one new part into the Navy Supply System at SPCC 
is about $1500. It has also been estimated that the Navy 
realizes $20,000 to $40,000 per year in Integrated Logistic 
Support (ILS) cost savings through a standardized system 
like UYK-20. 

Standardization avoids duplication of support software 
costs. A project manager estimated a savings of $2,000,000 
to $4,000,000 per year in software maintainance costs for a 
project using a standard computer. 

Standardization reduces the scope of required 
maintenance training. The Chief of Naval Technical Training 
emphasized this fact in a letter to the Director of TADSO , 
pointing out that it was becoming increasingly difficult to 
fill technical training billets, and that standardization 
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programs like AN/UYK-7 help alleviate this problem .[ Ref. 1 ] 
It is estimated that about $409,000 per year savings in 
technical training costs is realized through the existence 
of UYK-20. 

Standardization can reduce the amount of training 
required for operator personnel. Lack of standardization 
may mean that as an operator is transferred from one command 
to another he must be sent back to school to learn new 
equipment. Such an occurrence has a direct impact on fleet 
readiness and personnel training costs. As an example, the 
EEWSON program faces this problem because some of its shore 
installations utilize DSC PDP-11 computers while the 
associated shipboard installations employ AN/UYK-20 Data 
Processing Systems. 

Standardization saves the repetitive acquisition costs 
of procurements of unique systems. These costs include the 
recurring costs for ILS, software maintenance, etc. and also 
the one-time development costs. As an example, the OYK-20 
acquisition required $1.3 million in Research & Development 
funding for militarization of commercial hardware, support 
software, documentation, etc. 

Despite these strong arguments in favor of 
standardization, there is much resistance to any 
standardization program. Mr. Howard Gantzler, Deputy 
Assistant Secretary of Defense (Installations & Logistics) , 
recognized that attitude when he stated at a seminar given 
at the Naval Postgraduate School in January 1976, 



"Everybody is in favor of it [standardization], but 
nobody wants to adopt someone else's standards." 



Rear Admiral E. B. Fowler, Vice Commander of the Naval 

Electronics systems Command identified another drawback of 

standardization in an address to the Naval Postgraduate 
School chapter of the IEEE in April 1976. 
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"You have to standardize. You can't afford not to do 
so. But you must also get a firm grip on the half-life 
of the thing you are standardizing... AN/OYK-20 was 
thought at first to be a five year investment. We are 
currently reprocurring, and it looks like ten to 
fifteen years. The CP-642B»s [CP-642B computer (UNIVAC 
1212). See Chapt. II, Sect. D. ] have been around for 
sixteen to seventeen years, and we put them on the 
Nimitz, the newest capital ship. This is a systems 
engineering problem." 

In that statement Admiral Fowler suggests that once a 
standard is established, it may be used for many more years 
than anticipated unless a firm policy for replacement is 
adopted at the outset. Understandably, the majority of 
opposition to standardization was found by this author in 
the technical community, which must design systems using 
standardized components not specifically tailored to the 
tasks required. 



C. THE RANGE OF CAPABILITIES NEEDED 

In January 1972, a Design Review Group (DRG) was 
convened by TADSO to translate the requirements of the Navy 
for a minicomputer system into a specification which could 
be used as the basis for competitive bidding. It is 
significant to note that the intent was not to fill the 
entire range of size and power below the UYK-7, but only to 
fill the identified current and future needs. Thus, from 
the outset the success of UYK-20 depended on accurate 
prediction of those needs by the DRG. The composition of 
the DRG was most important, and it is interesting to note 
the commands represented: Naval Ordnance Systsms Command 
(ORD-532) , Naval Ships Systems Command (SHIPS-0352'4 ) , Naval 
Air Systems Command (AIR-5333F) , Naval Ships Engineering 
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Center (SEC-6178D and SEC-6172), H . Q. Marine Corps (Code 
AAM-4) , Fleet Combat Direction System Support Activities 
Pacific and Atlantic, and Naval Weapons Laboratory Dahlgren. 
The Naval Ordnance Systems Command and the Naval Ships 
Systems Command have since been combined into one command 
designated the Naval Sea Systems Command (NAVSEA) . Thus all 
the commands responsible for systems development were well 
represented. 

In order to save time and development costs, TADSO had 
conceived an "off-the-shelf" procurement. That was an 
important decision, which implied that the intent was to 
procure a market-tested computer system which would only 
need to be militarized. 

Since the computer was to be general purpose and serve a 
wide range of diverse applications, a modular building block 
approach was conceived. A basic configuration was to be 
specified and plug-in modules provided so that the user 
could increase the size and power of the processor up to his 
individual needs. Add-on modules were to be individually 
priced so that the user only paid for the capability he 
needed. The following paragraphs summarize the range of 
capabilities which TADSO and the DRG foresaw would be needed 
to meet Navy systems requirements of 1972 and about five 
years into the future. 

1 . Packaging 

The computer would be required to meet military 
specification HIL-E-16400 for shipboard, groundbased, and 
submarine electronic systems. This decision precluded 
airborne applications of the computer, which would have 
required the more stringent and expensive MIL-E-54G0 
specification, but would have expanded the applications and 
thus the volume of production. The reason behind that 
decision was the intention to produce an interim standard 
shipboard computer to be eventually replaced by the 
All-Applications Digital Computer (A ADC) which was then 
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under development by the Naval Air Systems Command (NAVAIR) . 
The AADC never materialized, and as of 1975 the AA DC project 
had been redirected to produce an Interim Standard Airborne 
Digital Computer (ISADC) • Out of the ISADC project came the 
AN/AYK-14 computer in 1976, 

The computer was to be packaged in one enclosure of 
maximum dimensions 26 inches high, 24 inches deep, and width 
suitable for mounting in a standard 19-inch rack- Maximum 
power consumption was to be one kilowatt. 

To achieve the desired building block capability, 
the following units were to be strictly plug-in with no 
other hardware changes necessary to install: memory modules 
of 8K-words per module, I/O channels in groups of two if 
serial and in groups of four if parallel, real-time clock, 
general registers, and microprogrammable control memory. 

2. Reliability and Maintainability 

In accordance with MIL-E-16400, modular construction 
was specified. All assemblies with a cost of $200 or less 
would be throw-away compoQents. Only those assemblies where 
it was. determined that repair would be more cost-effective 
than throw-away/replacement would be designated as 
repairable modules. It was further specified that repairs 
would be performed by the contractor, a factor which had a 
later impact on the repairable turn-around time. 

The maximum configuration of the computer was to 
have a Mean Time Between Failures (MT3F) of 2000 hours, a 
Mean Time to Repair (MTTR) of 15 minutes and a Maximum Time 
to Repair of 120 minutes. The MTBF specified was a figure 
which had been used on previous military computer 
specifications. As far as the author of this thesis could 
determine, the basis for citing the 2000 hour figure was 
historical rather than the result of calculation. 

The computer was to be logically and electrically 
designed to facilitate the isolation of malfunctioning 
modules through diagnostic programming. The diagnostic 



22 



program was to isolate 95% of recurring (non-intermittent) 
active logic element failures to not more than three printed 
circuit card modules. 

3 • Architectu re 

The computer was to employ third generation 
technology with the use of medium-scale integration. 

Perhaps the most significant architectural 
requirement was that the processor was to be 
microprogrammable. The rationale for requiring this 
capability was the possibility of a more powerful 
macro-instruction set and the flexibility to modify or add 
to the macro-instruction set by simply modifying the 
contents of control memory. An additional requirement was 
therefore for at least 500 words (16-bit) of user growth 
capacity in the control memory. 

Other required architecture attributes were: word 
length at least 16-bits including sign but not including 
parity, random access non-volatile memory with a separate 
high speed memory desireable but not required, main memory 
read-restore cycle time less than 1.2 microseconds, 
asynchronous timing with at least one level of memory fetch 
instruction overlap to create an effective memory cycle time 
of less than one microsecond, minimum storage capacity of 
8K-words expandable to at least 65K-words (directly 
addressable) in 8K-word increments, a minimum of four 
general registers expandable to sixteen. 

It was significant that no requirement was made for 
a capability to expand memory capacity beyond 65K-words. 
Also significant was the absence of requirements for parity 
checking, memory write protection or executive mode with 
privileged instructions. 

The question of parity checking was a much discussed 
attribute. Those in favor cited the need to identify 
hardware errors, particularly in memory accesses, when 
attempting to debug software. In addition, arguments were 
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made in favor of identifying errors when executing 
operational programs to prevent miscalculations of target 
information, misrouting of data (particularly in message 
handling systems) , mishandling of classified information/ 
etc. The arguments against parity pointed to the 
significant cost in real estate (extra bits and about 10% 
more logic) and extra memory bits per word. It was argued 
that parity error detection had little value in modern 
digital equipment since this attribute was designed to 
detect single bit failures rather than catastrophic logic 
failures affecting whole blocks of addresses; the latter 
type of failure characterized the type of failure most often 
encountered in modern equipment. Operationally it was 
thought undesireable to interrupt processing of critical 
target data to process parity errors in a combat situation. 

In the end the cost considerations prevailed. 
Although the question of memory protection was not discussed 
to the same extent as memory parity checking, similar cost 
and real estate savings could be realized by not including a 
hardware memory protection feature in the design. 

The macro-instruction set specified provided for 
single and double word addition, subtraction, 
multiplication, division, logical operations, shifts, jumps, 
and a programmable stop. In a non-dual-state machine the 
programmable stop would be non-privileged, making it a 
controversial attribute. Only load, add, subtract and store 
byte operations were specified, and no bit manipulation 
instructions were required. It is significant that all 
operations specified were arithmetic (recognizing the most 
significant bit of a word as the sign) so that no capability 
for full 16-bit data manipulation was required. Instruction 
execution times were specified as follows: 



Instruction Register -to- Register Me mory - to- Re gister 
Add, Subtract 1.2 microseconds 2.2 microseconds 

Load, Store N/A 2.2 microseconds 
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Multiply 
Divide 

Shift (16-bit) 



9 microseconds 
20 microseconds 
7 microseconds 



11 microseconds 
22 microseconds 
N/A 



The computer was to be capable of executing not less than 
500,000 instructions per second for the following 
distribution of memory-to-register instructions: 

Instruct ion Type Percen t of Mix 

Add, or equivalent 34 
Logical or masking 34 
Branch (Jump) 18 
Multiply 5 
Divide 1 
Miscellaneous _J3 

100 

The choice between one 1 s-complement or 

two's-complement arithmetic was left to the contractor, 
despite the fact that most previous Navy computers were 
one's-complement machines. That decision would impact on 
future software compatibility and system integration. 

The DRG specified at least single-level indirect 
addressing, indexing, and relative addressing to a fixed 
base which could be program modified. 

A hardware (or firmware) capability to load programs 
(bootstrap) was to be provided. The intent was that the 
bootstrap would be a plug-in option wherein the user could 
obtain bootstrap capability for the particular peripheral 
and channel desired. 

4 . Input/Output 

It was intended that the I/O structure be such that 
the I/O channels access memory through a second memory port, 
eliminating interference with processor operations. This 
requirement meant that an arithmetic unit, data registers, 
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etc. were required for each channel to perform buffer 
control functions, address calculations, interrupt control, 
etc. In order to save oq real estate, the channels (a total 
of sixteen) were to be grouped in increments of not more 
than four channels for parallel mode, or two channels for 
serial mode. Only one aider and set of data registers plus 
control circuitry would be required per four channel group. 
This requirement, while saving circuitry and cost placed 
several significant restrictions on possible I/O 
configurations: 

* For parallel mode data transfer, each four channel 
group was constrained to one type of interface. 

* Serial and parallel channels could not be mixed 
within a group. 

* Double word (32-bit) transfers, such as necessary for 
interfacing with UYK-7, would require one channel 
from each of two adjacent groups, thus forcing eight 
channels to be of the same type of interface. (This 
requirement stems from the need for separate 
processing circuitry for the upper and lower 16-bits 
of 32-bit parallel transfers.) 

Direct Memory Access (DMA) was desired but not 
required. Thus, a provision for direct memory access by a 
high speed mass storage device (such as a disk) could 
somewhat compensate for the lack of provision for expansion 
of main memory beyond 65K-words. 

Various types of interfaces were to be provided as 

options: 

* Parallel (MIL-STD- 1 397) 

■ NTDS Fast (-3 volts) 

• NTDS Slow (-15 volts) 

■ ANEW (+3.5 volts) 
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* Serial 

■ RS-232C synchronous and asynchronous normal 
speeds 

■ MIL-STD-188C synchronous and asynchronous normal 
speeds 

■ MIL-STD-1397 (NTDS) 32-bit serial 

■ MIL-STD-188C high speed (up to one million bits 
per second) 

All parallel types were to provide full duplex 
operation in a normal data transfer (16- or 32-bit) mode r an 
intercomputer mode, or an externally specified address (ESA) 
mode. Asynchronous serial channels were to provide 
full-duplex operation at bit rates of 75 r 150 r 300 r 600 r and 
1200 bits per second (baud) with 2400, 4800 and 9600 baud 
desireable. 

5 . Interrupts 

A priority structure of interrupts was specified 
with the following types of interrupts required (in order of 
priority, highest to lowest) : power failure protection, 
instruction fault, real-time clock overflow, internal clock 
interrupt, intercomputer time-out, external device interrupt 
and I/O interrupts. 

Despite the usefulness of nesting interrupts, the 
specification required only that interrupts occuring 
simultaneously be nested. Furthermore, the specification 
required that all interrupts of lower priority be disabled 
while processing an interrupt. 

6 . Cont rol /Maintenance Panel 

The specification required that a 

control/maintenance panel be provided that could be, but was 
not required to be separate from the computer. Noraal panel 
displays, indicators and controls were to be provided (these 
were specified in detail) . Significantly, the panel could 
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be configured to display only one register at a time, or 
more, as the manufacturer wished. 

7 . Sof t war e 

It is significant that the question of software was 
not addressed in the specification generated by the DRG. In 
the Request-f or-Proposals (RFP) only an assembler was 
required . 

Appendix B summarizes the specifications for the 
standard minicomputer system as determined by TADSO and the 
DRG. 



D. CAPABILITIES OF EXISTING NAVY COMPUTERS TO MEET THE 
SPECIFICATIONS 

It is valid to investigate whether the perceived present 
and future needs of the Navy for a minicomputer, as defined 
by the DRG, could be met by an existing general purpose 
small computer in the Navy inventory. If so, this computer 
could be designated a standard just as the AN/UYK-7 had been 
a year before. 

The sections below discuss the pertinent features of 
some of those Navy computers which would have been most 
likely to fill the need for a standard minicomputer. 
Appendices C through F summarize the characteristics of 
those computers. 

Comparing the standard minicomputer specification with 
the existing computers reveals that none met the 
specification completely, although two were good candidates 
with certain exceptions. The AN/UYK-15(V) lacked 
microprogramming and relative addressing, but was otherwise 
acceptable. It had additional features such as memory parity 
checking, memory write protection and multi-ported memory 
banks to further recommend it. The AN/UYK-12(V) also lacked 
microprogramming and did not meet all required instruction 



28 



execution speeds or memory capacity, but had an extensive 
support software package to recommend it. 

The existence of OYK-12 and UIK-15 brings the decision 
to specify a microprogrammed processor under close scrutiny. 
As discussed in the previous section, the advantages of 
microprogrammability are an expanded macro-instruction set, 
ability to implement high speed floating-point, mathematical 
and trigonometric functions as needed, and flexibility to 
add high-speed user macros to facilitate real-time 
processing. The disadvantages were best summarized in 
enclosure (1) of a letter to TADSO from the Naval Air 
Systems Command (AIR-5333) , 

"The latter deficiency [the requirement for 
micro-programmabili ty ] , while being technically 
feasible, leads to unusual hardware and software 
configuration management problems. NAVAIR believes 
that a requirement for micro-programmability has not 
been demonstrated and will serve only to eliminate 
qualified vendors. "[ Ref, 13] 

NAVAIR* s comments about configuration management refer 
to the potential user capability to modify the 
macro-instruction set. It must be pointed out that 
configuration control can be maintained by requiring that 
all modifications to the macro-instruction set be upward 
compatible with the basic set. 

The foregoing comments not-withstanding, 

microprogrammability remained a requirement, and none of the 
existing Navy computers could meet the specification. It is 
also interesting to note that a majority of the computers in 
the Navy inventory were manufactured by the UNIVAC Defense 
Systems Division of Sperry Rand Corporation (UNIVAC) . The 
Rolm Corporation manufactured AN/UYK- 12 (V) is an exception, 
and there were others. Comparison of the standard 
minicomputer specification with the UNIVAC manufactured 
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computers reveals that the DRG was probably influenced by 
the ONIVAC design philosophy in producing their 
specification. For instance, the OYK-12 I/O structure, 
which was not in accordance with the specification, was 
simply another method of accomplishing the same end. It is 
the opinion of this author that the use in the RFP of the 
detailed technical specification produced by the DRG rather 
than a performance specification, probably excluded some 
candidate minicomputers from the competition. 

1. CP-642B 

This computer, a militarized version of the ONIVAC 
1212, was an upward compatible follow-on to the 
0SQ-20/CP-642/CP-642A family. Designed specifically for use 
in the Navy Tactical Data System (NTDS) , its architecture 
optimized processing of large quantities of complex data 
where heavy I/O comunication was required. With reference 
to App. C it can be seen that although CP-642B was a 
minicomputer in capabilities, it was a physically larger 
unit than desired. Its size and slow speed are a result of 
its second generation architecture. Lack of serial I/O 
capability, lack of interrupts and limited memory were other 
factors which made this computer unacceptable. Appendix C 
profiles the CP-64 2B. 

2 . AN/OYK-15 ( V) 

The shortcomings of this computer, a militarized 
ONIVAC 1616, have been previously discussed. Additional 
desireable features incorporated in the AN/OYK-15 (V) include 
optional additional general registers up to 64, memory 
parity checking and a priority structured, multi-ported 
memory. This latter feature incorporates a priority 
multiplexer which provides four access ports for each 
16K-word memory bank. Combined with separate IOC's for each 
group of four I/O channels, this feature allows simultaneous 
access to different memory banks by the CPU and various 



30 



IOC's, thus improving throughput. Appendix D profiles the 
AN/UYK-15 (V) . 

3. SO 

Commercially designated the ONIVAC 1289, this 
computer was designed for navigation system applications. 
Although of second generation technology, it featured 
reasonable speed. It failed in a number of ways to meet the 
standard minicomputer specification, but it had some 
capabilities not required, but desireable: dual states 
(program and executive) , programmable memory read/write 
protection, memory parity checking, and floating-point 
hardware. Appendix E profiles the CP-890. 

4 . AN/UYK-12 (7) 

That computer was designed from the ground up as a 
militarized Data General NOVA with a military application 
I/O structure added. Designated the Rolm 1601, it was 
completely upward compatible with the NOVA and could thus 
run all software developed for that popular minicomputer. 

The I/O structure was basically a single I/O bus 
with the facility to address 61 different devices. Each 
device could independently interrupt the processor according 
to a predetermined priority. The computer could be 
configured with up to 16 I/O interfaces and 15 backpanel 
connectors. 

An extensive package of well-tested and 
well-documented support software was available. Included 
were cross-assemblers and cross-compilers so that programs 
for the UYK-15 could be assembled or compiled on a larger 
machine. That feature recognized the constraints on using a 
minicomputer for program development. 

In this chapter the meaning and implications of a 
standard minicomputer have been established. The Navy 
requirements for a minicomputer system in 1972 were 
discussed, and it was concluded that no existing small 
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computer in the Navy inventory could meet those 
requirements. In Chapt. Ill the history of the standard 
minicomputer acquisition project will be discussed. 
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Figure 2 - AN/UYK-20 ( V) SYSTEM USERS 



III. DEVELOPMENT AND PRODUCTION HISTORY 



The events leading to the publication of a specification 
for a standard minicomputer have been detailed " in the 
previous chapter. This chapter will relate the history of 
the AN/UYK-20 (V) acquisition from specification to mid-year 
1976. Much of the information on events leading to the 
contract award in May 1973 was derived from a research paper 
by Captain J. S. Sansone [Ref. 14 ], who was the Project and 
Contracting officer for the standard minicomputer 
procurement. 

In June 1972 the preliminary specification for the 
standard minicomputer was distributed for final review. By 
that time TADSO was well established and had issued six 
TADSTANDS on a variety of subjects. [Refs. 2-8] The 
acquisition strategy called for militarization of a 
commercial system requiring a minimum of system development 
to meet the DRG specification. It was estimated that about 
$1.8 million in Research, Development, Test and Evaluation 
Navy (RDT&EN) appropriated funds would be necessary to cover 
costs of design and devalopment, militarization, Government 
Furnished Equipment (GFE) , environmental and reliability 
testing, TEMPEST testing, Integrated Logistics Support 
plans, development of technical manuals, other data 
requirements, and support software development. 

In late August 1972 CNM advised CNO«s Director of 
Research, Development, Test and Evaluation (OP-098) of the 
existance of the standard minicomputer specification, and 
the need for prompt approval to preclude further 
proliferation of commercial minicomputers in the Navy 
inventory. OP-098 was also informed that the necessary $1.8 
million in RDT&EN funds could be obtained by repr ogramming 
Fiscal Year 1973 funds from sub-allocations to the various 
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projects who would use the standard minicomputer. Since the 
amount of funds to be reprogrammed did not exceed $2 
million, prior approval from the Secretary of Defense 
(SECDEF) and the Armed Services and Appropriations 
Committees of Congress was • not required. Reprograraming 
could be carried out within the Department of the Navy with 
the approval of the budget activity sponsor (OP-098) . There 
was sufficient justification for this plan since the user's 
funds would have been used for a computer procurement 
anyway. However, the plan raised potential user project 
manager objections. First, control over the design and 
development of the minicomputer would be taken out of the 
hands of the project managers and vested in an independent 
office. Second, great risks were involved in the delivery 
schedule. Third, ELEX-560 could not have the specific needs 
of all the user projects at heart when making tradeoff 
decisions regarding cost, schedule and performance. 

By mid-September 1972 the approval of CNO was assured. 
CNM tasked the Commander, Naval Electronic Systems Command 
(CCMNAVELEX) to handle the procurement. In response, 
C0MNA7ELEX created a division within his Material 
Acquisition Directorate (ELEX-05) to carry out this task. 
The division was designated the Standard Tactical Digital 
Equipment Division (ELEX-560). [Fig. 3] At this time the 
procurement plan specified a formally advertised two-step 
procurement based on the DRG specification and resulting in 
a firm-fixed-price contract. 

In October 1972, in response to TADSTAND 1, TADSO 
received a request from the Mk68 Gunfire Control System 
(GFCS) project to deviate from the UYK-7 standard in favor 
of a commercial minicomputer. The request was subsequently 
denied, and the requirements of the Mk68 GFCS project became 
the first firm requirements for standard minicomputer 
systems. The constraints of the Mk6'8 GFCS project schedule 
were thus imposed on the standard minicomputer procurement. 

The new schedule constraints forced abandonment of the 
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formal two-step procurement in favor of an accelerated plan. 
The plan called for a negotiated procurement under 
paragraphs 2304 (a) (2) and (10) of Title 10 of the United 
States Code, Those regulations allowed a negotiated 
procurement in lieu of a f ormally-advertised, sealed-bid 
competition in cases where the exigency would not permit the 
delay incident to formal advertising and when it was 
impractical to obtain competition. Significant milestones 
adopted were: 

* Issuance of the Request for Proposals (RPP) by 1 
December 1972 

* Award of the contract by 22 Pebruary 1973 

* Delivery of the first Functional Demonstration Models 
(FDM - non-militarized prototype) 30 days after award 
of contract 

Commencement of testing by 22 September 1973 

Delivery of the first Advanced Production Engineering 
Models (APE - militarized prototype) nine months 
after award of contract 

* Delivery of the first production units by May 1974 

Technical evaluation (TECHEVAL) would be completed in the 
contractor's plant and operational evaluation (OPEVAL) would 
be completed concurrently with the OPEVAL of the first user 
system. A firm-fixed-price contract was anticipated. The 
accelerated plan precluded detailed analysis of proposals to 
determine which contractor offered the best performance per 
price. It was planned to simply select the lowest bidder 
among those found responsive to the DRG specification. 
Thus / little improvement on the DRG design was possible 
through the acquisition process. 

On 15 November 1972, CNM declared the DRG specification 
as the Navy standard minicomputer specification and 
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constrained all projects planning or procuring minicomputers 
to use the standard as Government Furnished Equipment unless 
approval was obtained from TADSO to deviate. [Ref. 15] Three 
projects in addition to Mk68 GFCS were specifically directed 
to switch to the standard minicomputer for their production 
phase: the SPS-48 Radar Improvement Program, which had gone 
through development with the AN/UYK-15 (V) computer; the 
Carrier Tactical Support Center project (CVTSC) , which had 
gone through development with the IBM SP-1 computer, and the 
Satellite Communications program (SATCOM) , which had gone 
through development with the Rolm Corporation 1602 computer. 
This directive was probably premature since all projects 
were then forced to include in their production plans a 
component that was only a piece of paper with no proposals 
in hand to guarantee the feasibility of meeting the proposed 
schedule milestones. 

The establishment of the specification as a standard 
resulted in identification of more projects requiring a 
minicomputer. As of mid-November 1972 estimated 

requirements for some 314 production units (through Fiscal 
Year 1974) had been identified. Since this figure was 
expected to change, and delivery dates were not known, 
ELEX-560 proposed an Indefinite Delivery, Requirements type 
contract. Competition would be based on unit price per lot 
quantity for a specified system configuration plus prices of 
certain add-on modules. By mid-November 1972, 25 firms had 
indicated a desire to submit proposals and none were thought 
to be unresponsive. A fully competitive procurement seemed 
assured. 

The RFP released on 1 December 1972 cited the milestones 
previously listed and a three year production run. Each 
year's production was an option to be priced separately so 
that the contractor could protect himself from inflation. 
The RFP contained estimated production requirements for each 
year to protect the contractor from the high risks of 
bidding on unknown production quantities. Production funds 
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would be obtained directly from the users at the time they 
placed orders under the annual Requirements Contracts. The 
RFP also specified a government option for rights to the 
technical data to provide for a competitive follow-on 
procurement. 

At this point some comments should be made about the 
acquisition strategy. First, a great deal of the success 
hinged on obtaining adequate competition. Without it, there 
would be little to choose from as far as system design and 
price. Second, the desire to select the lowest bidder 
precluded opting for a better design at a slightly higher 
acquisition cost, thus achieving better performance and 
reliability and possibly a lower overall life-cycle cost. 
Third, unless later funding for the standard minicomputer 
project was forthcoming from Operations & Maintenance Navy 
(O&MN) appropriated funds, the users would bear the costs of 
support software maintenance and enhancements, system 
improvements, maintenance of documentation and other support 
costs. This was a point that worried user project managers. 
Put simply, if the orders stopped the funding would stop, 
and the system would no longer be supported. 

By the end of December 1972 the estimated award date had 
slipped to 1 March 1973 because of changes to the RFP. 
Those changes resulted from substitution of the CVTSC 
project requirements for the Mk68 GFCS requirements when the 
latter project's funds were cut. At that time there were 
also growing complaints from interested companies that the 
RFP closing date was too soon, the specification was too 
restrictive, and the delivery date for FDM 1 s was 
unrealistic. Because of these points, plus the unspoken 
consensus that the specification favored one company's 
design philosophy, about 19 of the original 25 interested 
firms declined to submit proposals. Included in these 19 
were IBM Corporation, Rolm Corporation, Control Data 
Corporation (CDC) , and Digital Equipment Corporation (DEC) . 
The competition was rapidly vanishing. 
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The options open to the Navy at this point were as 
follows: 

* Maintain the schedule despite the high probability of 
a sole-source procurement. 

* Slip user project schedules in order to extend the 
proposal due date and gain more competition. 

* Cancel the RFP and restructure the procurement as a 
development effort. 

The decision was to slip the closing date for receipt of 
proposals to 2 April 1973 and extend the date for delivery 
of FDM ' s to 120 days after date of contract. Since this 
schedule might not meet some potential user schedules, a 
risk of losing some firm requirements had been accepted. 

During the month of February 1973 two formal protests on 
the RFP were filed with the Government Accounting Office 
(GAO) . The first, from Control Data Corporation, was 
satisfied by the extension of the due date for proposals. 
The second, from QNIVAC, objected to the extension on the 
grounds that the company had spent considerable effort and 
funds to meet the original dates. An important point 
brought out in this latter protest was that no firm had a 
computer that would meet the specification completely, and 
that substantial design and development effort were 
necessary in all cases. GAO subsequently determined that no 
violation of procurement law had occurred, and ONIVAC's 
protest was denied. 

Although not required for a procurement of such low 
estimated dollar value ($1.8 million), a Source Selection 
Authority (SSA) , Source Selection Advisory Council (SSAC) , 
and Source Selection Evaluation Board (SSEB) were 
designated. The SSEB consisted of the DRG plus 
representatives of NAVEL EX, the Marine Corps and TADSO. The 
SSAC consisted of representatives of NAVELEX and TADSO with 
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expertise in management systems, cost analysis, logistic 
support, etc- The SSA was COMNAVELEX with the advice and 
consent of CNM. 

On 2 April 1973 proposals were received from ONI VAC, 
CDC, General Electric and Raytheon. The SSEB proceeded to 
evaluate the proposals without knowledge of prices and found 
all firms to be responsive to the DBG specification. The 
SSAC determined that adeguate price competition existed. A 
pre-award survey was conducted at each plant during the week 
of 16 to 20 April 1973. All offerers were found to be 
technically and financially responsible and responsive in 
accordance with Armed Services Procurement Regulation (ASPR) 
1-903. contract award was made to the low bidder, QNtVAC, 
on 27 April 1973. The contract included all hardware 
requirements plus an assembler for a firm-fixed-price of 
$673,000. 

Soon after contract award, user requirements for 
additional support software in addition to the assembler 
were identified. To meet this need, sole-source contracts 
were let to 0NIVAC for two self-hosted systems. The first, 
designated Level I, was released in November 1973. The 
second, designated Level II, was released in January 
1974. [App. G] NAVELEX also contracted with UNIVAC at that 
time to develop two other support software packages: a 
standard real-time executive later designated SDEX-20, which 
was to provide users with basic software modules upon which 
to build their operational programs; and a compiler for the 
Navy standard high-level language (CMS-2) , which would 
generate machine code for the UYK-20. This high-level 
language for the UYK-20 was designated CMS-2M and was to be 
a subset of the CMS-2 language. These additional contracts 
were funded from the balance remaining of $1.3 million in 
RDT&EN funds reprogrammed for the UYK-20 acquisition. 

In May 1973 TADSO revised TADSTAND 1 to designate the 
UYK-20 as the Navy Standard digital processor for those 
applications requiring a minicomputer. [Ref. 3] As expected, 
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this action generated a few requests for deviation from that 
standard. Most were turned down. The Submarine Integrated 
Radio Room (IRR) project, which was developing with the CDC 
MPP computer and the AN/UYK- 1 5 (V) , had a request to deviate 
denied on the basis that the UYK-20 was upward compatible 
with the UYK-15. Very few requests for deviation were 
granted. The VERDIN retrofit project was granted a waiver 
due to size problems in retrofitting equipment into a 
submarine, and the necessity for compatibility with existing 
equipments. The SEA SCOUT project was granted a waiver 
since two systems were already deployed with the 
AN/UYK-1 2 (V) , urgent requirements existed for four more 
systems, and no more than a total of six systems were to be 
acquired. The BULLSEYE project was granted a waiver to use 
the DEC PDP-11 computer as its shore-site cryptologic 
processor. Justification for that waiver was that the 
PDP-'ll was currently in use at shore sites, associated 
engineers and support systems were available, and shipboard 
use was not anticipated. 

On 27 March 1974 the UYK-20 received service approval. 
A major milestone in any program, this event also had a 
profound impact on the funding of the project. Once service 
approval was received, the activities of ELEX-560 could no 
longer be supported with RDT&EN funds. Since no Operations 
& Maintenance Navy (O&MN) funds were available to support 
the project, NAVEL EX was forced to assess users of the 
system for system support in the following manner. The 
DYK-20 contract was a Requirements, Indefinite Delivery 
contract which allowed the users to purchase systems and 
components by transmitting a DD Form 1155 (Order for 
Supplies or Services) to ELEX-560 with an order form 
attached. The user's funds were obligated via the DD Form 
1155, and the order form provided a detailed description of 
the equipment and software requested. The user obligated 
funds according to a published price list. These published 
prices included a surcharge over the fixed prices in the 
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contract; it was this surcharge which was used to fund 
ELEX-560 support activities. 

Occasionally users would require new system components 
(e.g. bootstraps , I/O interfaces, and/or peripheral handler 
software routines for a unique peripheral device) . 
Naturally the requesting user had to provide funds for the 
development of his unique requirement. This was 
accomplished by submitting a DD Form 1149 (Requisition and 
Invoice/Shipping Document) to ELEX-560 with a description of 
the needed material. ELEX-560 would use the authority 
transmitted by the DD Form 1149 to obligate the user's funds 
on a sole-source Time and Materials type contract with 
ONIVAC for the development effort. 

Accounting for the surcharge and the myriad of 
appropriation budget activities cited by the users was an 
elaborate task. Frequent liason with ordering activities 
was necessary to insure that surcharges were "paid" out of 
appropriation catagories which could be properly used by 
ELEX-560. For the most part 05MN funds were required to 
fund project tasks. 

The surcharge system concerned user project managers. 
Primary objections were (1) the necessity to pay prices 
above the fixed prices on the contract, and (2) the 
realization that if no orders were received the funding 
support for the project would dry up. Each year NAV3LEX 
requested sufficient O&MN funding to support the project, 
but those funds were never forthcoming. Project personnel 
believed that the project requirements were cut from the 
Navy budget submission by the Office of the Secretary of 
Defense (OSD) or the Office of Management and Budget (OMB) . 

In September 1974 the first issue of "The Standard" was 
published. This document was, as stated in its header, "a 
bi-monthly newsletter published to inform AN/OYK-2 users of 
current status and new developments that involve the 
AN/UYK-20 (V) computer and its support software." "The 
Standard" was a step toward solving the communications 
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problem, that plagues all bureaucratic organizations. 

About that same time the idea of a formal user's 
>rganization was conceived, and in November 1974 the first 
IN/UYK-20 User's Group meeting was held at the Naval 
Slectronics Laboratory Center (NELC) in San Diego. The 
neeting attracted some 200 persons from government and 
private industry. By mid-1976 the AN/UYK-20 User's Group 
*as meeting semi-annually in the Spring and Fall and boasted 
i membership of close to 300 persons. Each meeting provided 
i forum for ELEX-560 to transmit further information to the 
isers, but more importantly for the users to present ideas 
Ln briefings and presentations which would benefit other 
users. The meetings also provided an opportunity for users 
and project office personnel to meet face to face and 
iiscuss problems. 

At the November 1976 User's Group meeting at the Naval 
Postgraduate School in Monterey, the Fleet Combat Direction 
Systems Support Activity (FCDSSA) San Diego announced the 
release of a compiler for the UYK~20 computer. This 
compiler, designated CMS-2Y(20), operated under the SHARE/7 
operating system on the AN/UYK-7 computer. The compiler was 
designed to provide versatile program development 
capability, since it utilized the powerful programming aids 
available under SHARE/7. [App. G l 

By late-1974 the first UYK-20 computers had been 
received and were in use in the development of tactical 
systems. Many hardware failures were encountered in these 
early computers. The hardware problems were compounded by 
the fact that the diagnostic program package for the DYK-20 
was not available to users until November 1974. Users were 
dependent on UNIVAC field engineers to perform corrective 
maintenance. Errors were also encountered in the support 
software and in the documentation for both hardware and 
software. In general these problems were discovered and 
solved through trial and error, but with large expenditures 
of user time and funds. 
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The types of problems most often encountered during the 
early period in late-1974 were: Memory Array Board failures, 
Memory Control Board failures, broken or bent connection 
pins on printed circuit (PC) cards, defective power 
supplies, PC cards not seated properly, and software 
documentation which either contained erroneous descriptions 
of software capabilities or neglected to mention 
capabilities that' existed. The contractor, who was 
responsible for correcting many of the problems, submitted 
Engineering Change Proposals (ECP's) to NAVELEX to correct 
deficiencies. Because of a clause in the contract which 
required all production units to be identical, a retrofit 
was necessary to incorporate the approved Engineering 
Changes into production units already in the field. UYK-20 
serial number 350, which came off the production line in 
December 1975, became the baseline unit for the first 
retrofit. All 349 previous production units were affected 
in varying degrees. Retrofit I consisted of minor changes 
such as replacement of screws, mountings, and fittings, and 
major changes such as replacement of power supplies in 
serial numbers 1 through 12, replacement of PC cards which 
had been redesigned, and modifications to existing cards. 
The retrofit was performed in the field by UNIVAC engineers 
during the period from January 1975 to September 1976. 

Despite the discovery and correction of many 
deficiencies, by mid-1975 the frequency of failures in 
production units signified that a reliability problem did 
exist. Perhaps the best data base attesting to the 
suspected reliability problems came from the Naval 
Electronics Systems Engineering Center (NESEC) at San Diego. 
This activity was tasked with assembly and checkout of the 
Navy Message Address Communications System (NAVMACS) , which 
was one of the first systems using UYK-20 to reach the 
fleet. During the period late-1974 to mid-1975, NESEC San 
Diego reported that a high percentage of production units 
were received inoperative due to faulty PC cards and 
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assembly modules. Spares received were also defective, 
making trouble-shooting with the diagnostic programs very 
difficult. (Trouble-shooting procedures utilizing the 
diagnostic routines depended on substituting spare modules 
and PC cards for suspected defective parts.) Some failures 
were intermittant , making them extremely difficult to 
diagnose. 

Records at NESEC San Diego indicate that during the 
period late-1974 to mid-1975 many modules were experiencing 
60% to 70% failure rates. Particular problem areas were 
power supplies, Memory Array Boards, seating of I/O cards, 
and overheating in hot weather. It was found that over a 
significant period of operation, however, the failure rate 
would be substantially decreased, indicating that a 
"burn-in" period increased reliability. 

In response to the reports from NESEC San Diego, 
personnel from UNIVAC visited that activity and verified the 
need to upgrade reliability. In June and July of 1975 
UNIVAC voluntarily shut down the production line in 
Clearwater, Florida to investigate the possibility of severe 
Quality Assurance (QA) problems. Over the ensuing months 
the contractor took the following action to up-grade UYK-20 
quality: 

* Personnel Improvements 

■ Established QA as an independent organization. 

■ Transferred added QA technical and management 
capability from the main plant in St. Paul, 
Minnisota to the UYK-20 production plant in 
Clearwater. 

■ Hired additional quality engineers and 
inspectors. 

■ Added a program QA man in Clearwater. 

■ Transferred final testing to Manufacturing in 
order to remove schedule concerns and increase QA 
focus. 
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* Documentation and Procedures 

■ Reviewed and updated all inspection and test 
procedures. 

■ Established formal procedures for resolving 
Defense Contract Administration Service (DCAS) 
and UNIVAC quality concerns and for implementing 
corrective actions. 

■ Reviewed and improved assembly processes* 

■ Added automatic equipment. 

■ Introduced new material handling containers for 
PC cards. 

■ Developed new fixtures for holding memory arrays 
during assembly. 

* Training and Motivation 

■ Hired a full-time trainer. 

■ Established a dedicated training room. 

■ Instituted training programs for manufacturing 
and inspection personnel. 

■ Established certification criteria and 
recertif ication time periods for all key skills. 

* Management Reviews 

■ Increased local audits. 

■ Established formal defect trend reviews with 
manufacturing and QA. 

■ Implemented corrective action follow-up on key 
defects . 

■ Strengthened and increased management audits. 

After the June to July shutdown and the subsequent 
quality improvement program, UNIVAC experienced a 66% 
improvement in acceptance tests at the Clearwater plant. 
These improvements were felt by the users in late-1975 when 
a high percentage of computers received from the factory 
(were in operational condition. 
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In late-1974, in response to user demands, Univac 
developed a User's Handbook for the AN/OYK-20 (V) DPS. This 
handbook was written primarily for operational program 
development programmers and contained a description of the 
hardware and detailed descriptions of support software. The 
handbook was first released in early-1975 and by mid-1976 
had undergone four major revisions to correct numerous 
errors and incorporate new software systems. 

Early in 1975 SDEX-20 (the standard Real-Time Executive) 
and the CMS-2M compiler were released. Since CMS-2M was a 
subset of the CMS-2 standard high-level language, it became 
a standard also. OYK-20 users were required to write their 
operational programs in that language. A few projects had 
begun development using other languages, predominantly 
FORTRAN, and were unwilling to rewrite. Their objections 
cited schedule impact, increased development cost and the 
high risk associated with using an untested compiler. TADSO 
held a firm line, and most projects still in development 
were forced to switch to CMS-2M. 

Op to the beginning of 1975 no peripheral devices 
existed which were specifically meant for use in Navy 
tactical systems. It was rapidly becoming apparent that 
proliferation of diverse peripheral equipments was also a 
problem. By May 1975, 76 unique peripheral devices were in 
use with the OYK-20 computer. In February and March of 1975 
two contracts were let for peripheral devices which were 
destined to become standards for use in Navy systems: 

* A contract with QOANTEX, Peripherals Division of 
North Atlantic Industries Incorporated for a 
Cartridge Magnetic Tape Onit (CMTU) which was 
eventually designated AN/OSH-26 (V) . 

* A contract with UNIVAC for an Alphanumeric Display 
Device (ADD) , which was eventually designated 
AN/OSQ-69 (V) . 
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The acquisition strategy for these peripheral units was 
identical to that utilized in the standard minicomputer 
procurement. Requirements, Indefinite Delivery, 

firm-fixed-price contracts were awarded to the low bidders 
among those contractors found responsible and responsive to 
the RFP. The first standard peripheral production units 
were scheduled to be delivered in October 1976. 

As a result of its diversification into peripheral 
equipments and other areas, at the beginning of Fiscal Year 
1976 ELEX-560 was redesignated the Automatic Data Processing 
(ADP) Systems Division (ELEX-570) . With the redesignation 
came increased scope of responsibilities including: 

* Tactical ADP hardware development. 

* Tactical ADP software development. 

* Tactical ADP display systems development. 

In September and October of 1975 the Disk File Manager 
software and Machine Independent System Generator software 
packages were released. [App. G] 

In November 1975, at the AN/UYK-20 User's Group meeting, 
it was announced that a User's Group Software Directory 
would be published quarterly by the Publications Chairman of 
the User's Group. This directory was designed to inform 
users of the availability of operational and support 
software developed by other users. Although the concept was 
good, by May 1976 there were no suppliers of information on 
their software, although there were many requests for the 
directory. 

Also announced at the November 1975 meeting was an 
AN/UYK-20 Test, Analyse and Fix (TAAF) program. This 
program, to be carried out at the Naval Weapons Center at 
Dahlgren, was designed to accomplish the following 
objectives: 

* Perform a Navy conducted AN/UYK-20 reliability test 
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■ Detect any additional changes required to 
demonstrate a 2000 hour MTBF. 

* Establish a UYK-20 field data collection program. 

The test setup was to consist of four machines variously 
configured to excercise all hardware options. A total of 
12,000 hours of operation under steady-state temperature, 
voltage and frequency conditions was planned. Two of the 
machines were to be subjected to a total of 600 hours of 
vibration testing. In May 1976 the results of the TAAF 
program were reported to the User's Group assembled at the 
Naval Underwater Systems Center in New London.: 

* Corrective Action Items Identified 

■ Memory Array Board fabrication popped resistors 
and cracked cores. 

■ The master clock was overloaded. 

■ Miscellaneous logic gates were overloaded. 

■ A certain type of Read-Only-Memory (ROM) was 
defective and should be replaced. 

* Corrective Action items Installed 

■ An Engineering Change to eliminate clock 
overload. 

■ Increased QA inspection of Memory Array Boards 
and Power Supplies. 

* Observations 

■ No component reliability problems were detected. 

■ Reliability agreed closely with available field 
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The data gathered during the TAAF program showed that MTBF 
during the first 4000 hours of operation on the four 
machines remained low at about 500 to 600 hours. After 4000 
hours a steady improvement occurred so at the completion of 
testing (12,000 hours) the MTBF was about 1500 hours. The 
results of these formal tests essentially confirmed what had 
been suspected by users a year and a half previously - that 
memory boards and power supplies were a major cause of 
failures, and that a significant "burn-in" period was 
necessary for reliable operation. 

By the end of 1975 many design deficiencies had been 
corrected through Engineering Changes. The contractor had 
also requested waivers on certain deficiencies which he 
thought too rare to warrant attention. ELEX-570 approved 
two of those requests for deviation from the design 
specifications: circuit breaker trip under shock test, and 
Electromagnetic Interference (specifically magnetic 
radiation) test results. All other requests had been 
refused, but by the end of 1975 the contractor had failed to 
correct three deficiencies: 

* The NTDS serial I/O interface was experiencing signal 
reflections when cable lengths of 150 to 225 feet 
were used. 

* Onder certain conditions the condition code was not 
set properly during double precision subtract 
operations. 

* Onder certain conditions Floating Point Add/Subtract 
operations resulted in errors. 

As a result, the government stopped accepting production 
units from December 1975 to February 1976. This firm action 
caused the contractor to submit ECP ! s to correct the three 
deficiencies . 

Computer serial number 550, which was produced in 
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February 1976, became the base-line for a second retrofit. 
Retrofit II implemented the Engineering Changes to correct 
the three design deficiencies listed above plus six others. 
(About 90 Engineering Change Proposals had been submitted by 
that time.) 

Naturally, the two shutdowns put UYK-20 production 
behind schedule. At the aser»s Group meeting in May, 1976 
it was reported that 824 units had been ordered, but only 
637 delivered. 

At the same User's Group meeting ELEX-570 reported the 
establishment of an AN/UYK-20 Support Software Repository. 
The purpose of the repository was to collect and distribute 
as required to D. S. Government OYK-20 users, software 
developed by other U. S. Government users. This effort was 
designed to reduce software development redundancy and thus 
reduce development costs. Also reported to the User's Group 
was the impending release of a new technical manual, the 
first major revision of this document. 

This chapter has related the growing pains of a computer 
system from development through initial production. Many of 
the problems were to be expected in such a project. The 
unfortunate part of the UYK-20 history was that throughout 
this growth period users were dependent on the computer as a 
component in tactical systems under development. The early 
unreliability of this component compounded the problems 
encountered in developing those systems. The next chapter 
will discuss the impact of the UYK-20 computer on user 
systems during this period of growth. 
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IV, EVALUATION OF THE SYSTEM 

The previous chapters have been historical in nature, 
relating the events which marked the development and initial 
production run of the standard minicomputer. It is the 
purpose of this chapter to evaluate the system itself and 
the impact of UYK-20 , s growing pains on the development of 
those systems which used it as a system component. 

A. COMPARISON OF SPECIFICATION AND FINAL PRODUCT 

Chapter II, Section C and Appendix B discussed the 
specification upon which the AN/UYK-20 DPS acquisition was 
based. To complete the historical picture presented in 
previous chapters, it is necessary to briefly discuss the 
actual product which resulted from the standard minicomputer 
acquisition. For ease of comparison, App. H summarizes the 
characteristics of UYK-20 as it existed at mid-year 1976. 
Appendix B summarizes the DRG's specification. Appendix I 
lists the basic hardware configuration and options 
available. Appendix G describes the system support 
software. References 16 and 17 provide further details. 

By comparing Apps. B and H it can be seen that the 
UYK-20 system met or exceeded the specification in all major 
areas except reliability and maintainability. As discussed 
in the previous chapter, MTBF to 2000 hours has never been 
demonstrated. No empirical data on MTTR was available. It 
must be remembered that MTTR included localization of the 
problem, correction, alignment and calibration, and system 
checkout. It could be postulated that meeting an MTTR of 15 
minutes presumed that the diagnostic programs were ready to 
load (via magnetic tape or paper tape) , that the technician 
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was familiar with the diagnostic procedures published in the 
Technical Manual, and that a complete spares kit was 
available. If the trouble was isolated to a module which 
was missing from the spares kit, the MTTR would necessarily 
include time to procure the part. 

The UYK-20 represented improvement over the 
specification in the areas of speed, number of general 
registers, instruction repertoir, weight and power 
consumption. Weaknesses were in the memory addressing 
scheme and interrupt structure. Some weaknesses in the I/O 
structure were discussed, in Chapt. II. In addition, the 
Central Processor (CP) and the I/O Controller (IOC) ended up 
sharing the same memory port, with the IOC having priority 
over the CP. An optional Direct Memory Access (DMA) channel 
was provided, which accessed memory through a second memory 
port. This minimized interference between the CP/IOC and 
the DMA device, but the addition of the DMA capability added 
about 65 nanoseconds to the memory cycle time. An 
additional drawback was that the CP/IOC had priority over 
the DMA in accessing any particular memory bank. Since many 
accesses are sequential, . the CP could lock-out the DMA 
device from memory. Although it was not mentioned in the 
documentation, a jumper connection on a PC card could be 
modified to give the CP/IOC and DMA memory ports equal 
priority. 

There was no provision to expand main memory beyond 
65K-words. 

Although multi-level indirect addressing was possible, 
the procedure for implementation was awkward and involved 
setting indirect control bits in a status register and 
storing information in an Indirect Word. 

Sixty-four page registers existed so that main memory 
could be divided into 64 blocks of 1,024 words each. No 
memory protection existed, however, which was necessary to 
prevent inadvertant access to pages in memory by 
unauthorized programs. Also missing was a provision for a 
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privileged state (i.e. a set of privileged instructions 
vhich could be reserved for use by a designated executive 
program. The lack of those latter tvo capabilities 
prevented the efficient implementation of program swapping 
algorithms for multi-programming applications. The 
usefulness of the page registers was thus limited. 

The interrupt structure weakness primarily involved the 
inability to nest interrupts. If an interrupt from one 
class was interrupted by an interrupt from another higher 
priority class (there were three classes) , the lover 
priority interrupt would be saved while the higher priority 
interrupt was processed. However, only one storage area for 
saving status registers, prograa registers and real- tine 
clock existed per interrupt class. If an interrupt 
pre-empted another interrupt of the same class, the saie 
storage area would be reused and the previous program status 
would be lost forever. 

The instruction repertoir was extensive, reflecting the 
capabilities of micro prog raised control. Instructions were 
incorporated froa the AN/UTK-15 (7) instruction set to make 
the UYK-20 upward compatible with that machine. Although 
not required by the specification, significant capability 
for floating-point, mathematical and trigonometric functions 
existed in an optional module of microprogram routines 
designated the KATHPAC. Also available as an option was 512 
words of user specified microprogram routines, designated 
the Microgrowth. 

By 1976 there was available an extensive set of support 
software [App. G], but it must be remembered that the first 
systems only had an assembler program. The rest of the 
software was developed over the ensuing three years. 
Significant also was the fact that KTB? was much verse in 
the early months than the 1500 hours demonstrated in 1976. 

This section has briefly compared the kll/ r JI?-20 IPS with 
the DRG 1 s specification. In general more capability existed 
in the final product than vas originally requested, with 
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some important exceptions. Ensuing discussions will compare 
the UYK-20 with the "off-the-shelf" state-of-the-art in 
minicomputer design in late-1 972/early-1973. The 
discussions will provide further insight into the true 
capabilities of the AN/UYK-20 DPS • 

B. COMPARISON OF AN/QYK-20 DPS WITH THE 1972 
"OFF-THE-SHELF" MINICOMPUTER STATE-OF-THE-ART 

It has been stated previously that the standard 
minicomputer specification may have been too restrictive. 
If given the funding constraints, the acquisition strategy 
had embodied design-to-cost concepts, for example, so that 
the proposals could work toward the best system for the 
money guided by a performance specification, the final 
product may have looked much different. It would be 
difficult to postulate the cost of militarizing any 
particular commercially marketed computer system. It is 
beyond the scope of this thesis to predict what the 
proposals would have been, given the development funds and 
production prices eventually realized. This section will, 
however, discuss the technical possibilities available in 
late-1972 and early-1973. The intent is to consider that 
state-of-art which was through development and into 
production about the time of the standard minicomputer 
Request for Proposals (RFP) . The assumption is, as 
previously stated, that the Navy wanted to minimize time and 
development effort and so would look for a system which was 
ready for market. The discussions will also provide a 
further means of evaluating the AN/UYK-20 DPS. For 
information, four minicomputers representing the 1972 
technology are profiled in Apps. J through M. 

1 • Ar chitect ure 

Certainly the microprogrammed processor was the most 
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common architecture in 1972 minicomputers. Of the four 
examples, only the Digital Equipment Corporation PDP-11/45 
was not microprogrammed. Microprogramming' permitted a 
reasonably powerful instruction repertoir while minimizing 
size and electrical power consumption. Basically two types 
of microprogramming were used. Horizontal microprogramming 
utilized a long micro-instruction word where each bit 
controlled a specific register-transfer function. The 
Varian 73 with a 64-bit micro-instruction word was a good 
example of that design concept. The Rolm 1602 with a 32-bit 
micro-instruction word was a border line case. Vertical 
microprogramming utilized shorter micro-instruction words 
which required some hardware decoding in the control 
process. The Hewlett Packard 2100A with a 24-bit 
micro-instruction word and the UYK-20 with a 16-bit 
microinstruction word are examples of vertical 
microprogramming. The tradeoff between the two types was 
more .high-speed memory and simpler hardware logic for 
horizontal versus less memory but more complex logic in the 
case of vertical. A convenient capability in a 
microprogrammed processor resulted from the use of Writable 
Control Store (WCS) memory in place of Read-Only-Memory 
(ROM) . WCS memory allowed the user to alter the 
microprograms or add his own routines with the same ease 
encountered in storing programs in Random Access Memory 
(RAM) . By contrast, many ROM designs involved methods of 
program storage which were unalterable. Some minicomputers 
allowed a mixture of ROM and WCS in the control memory. 
This feature was totally lacking in UYK-20, even in the User 
Microgrowth section, which had to be factory produced. To 
circumvent this problem, FCDSSA San Diego developed a device 
called GENRAM which plugged into the User Microgrowth module 
slot of the UYK-20. This device, along with a microcode 
assembler, facilitated development and test of microprogram 
routines for the UYK-20. 

By contrast, the DEC PDP-11/45 achieved a powerful 
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instruction set through hardware implemented logic. To do 
so DEC sacrificed size and power consumption. By using 
high-speed bipolar logic and Large-Scale-Integra tion, DEC 
achieved much faster instruction execution speeds than 
possible with a microprogrammed architecture. For example, 
an Add instruction required only 0.3 usee contrasted with 
0.75 usee for the same operation in UYK-20 or 1.96 usee in 
HP2100A. 

Another architecture feature available on 
Minicomputers in 1972 was register "push-pop" stacks. The 
PDP-11/45 had an extensive stack, manipulation capability, 
but it was also available in a more limited way on smaller 
machines like the Holm 1502. A "push-pop" stack was a group 
of registers configured so that if a value was stored in the 
top register, all previously stored values were 
automatically "pushed" down to the register "below". If the 
stack was referenced by an instruction, the "top" value 
"popped" off and all values previously stored moved "up". 
Actually the stack was implemented through the use of a 
stack pointer register which always pointed to the "top" 
register on the stack. This was a last-in-first-out sort of 
operation. Stacks were useful for storing data that would 
be used in a preset order, such as nesting interrupts where 
the last machine state (values of the program counter, 
status registers and other important data) were "pushed" 
onto the stack, to be "popped" off when the last interrupt 
finished processing. The OYK-20 had no stack capability. 

Another architecture attribute was useful 
particularly where programs had to be swapped on and off a 
mass storage device as in a multi-programming environment. 
That attribute was a Privileged State. Basically, a set of 
instructions was provided which could only be executed while 
in that special state. Instructions which stopped program 
execution, altered memory assignments of programs, altered 
memory protection, etc. would be part of a privileged 
instruction set. Combined with features like memory protect 
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and paging hardware, the existence of a privileged state 
allowed powerful and efficient program swapping algorithms 
to be iaplemented. A privileged state was generally found 
only on larger machines like the PDP-11/45. 

2» Main M emor y 

Main memory generally was available in three types: 
magnetic core, Metal Oxide Semiconductor (BOS) and bipolar 
semiconductor. Core memory ranged in memory cycle speeds 
from 0.6 usee to 1.5 usee while semiconductor memories 
realized memory cycle speeds down to about 0.3 usee. The 
tradeoff was that semiconductor memories were volatile, 
reguiring additional power to refresh the data stored. 
Power failure would result in the loss of all stored data 
unless a backup battery power source was provided. Core 
memories were non-volatile and would retain data for very 
long periods of time. Core memories were generally less 
expensive than semiconductor, although LSI techniques were 
lowering the cost-per-bit of semiconductor memories 
drastically. Many minicomputers, such as the Holm 1602 and 
the Varian 73, offered a mix of memory types. 
Communications with memory were purposely designed to be 
asynchronous (speed independent) to allow future plug-in of 
higher speed memories as they became available. The UYK-20 
utilized core memory only. Memory protection capability and 
memory parity were not incorporated in the UYK-20 for 
reasons discussed in Chapt. II, Sect. c. Those features 
were available on some minicomputers (HP2100A and Varian 73) 
and almost always incorporated on larger computers like the 
PDP-11/45. Memory parity was usually implemented by the 
addition of two bits per memory word (one parity bit for 
each 8-bit byte) . Memory protect in minicomputers could be 
implemented by a single register of one bit per memory block 
or by one or more boundary registers which would contain the 
address of the upper and/or lower boundary of a protected 
memory block. Most minicomputers offered at least two 
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memory ports (i.e. channels) through which to access memory. 
The most common arrangement was for the CP to access memory 
through one port and a DMA channel through another port. 
Both the CP and the device on the DMA channel could access 
memory at memory cycle speeds. HP2100A featured three ports 
(two DMA channels plus CP). Access speeds of 1 r 000K-words 
per second were typical. 

A feature within the minicomputer state-of-the-art, 
but not often implemented, was interleaved memory. This 
memory addressing scheme placed consecutive addresses in 
different memory banks to eliminate one device locking out a 
particular memory bank with a large number of consecutive 
address accesses. PDP-11/45 featured interleaved memory as 
an option. 

The PDP-11 family of computers featured a unique 
architecture attribute. DEC connected all functional 
devices (CP , memory banks, I/O channels, DMA channels) to a 
single data/address bus called a UNIBUS. Each functional 
device was independent and could access any other device on 
the UNIBUS independently. In the PDP-1 1/45 every general 
register, memory location and I/O register was given equal 
status as a location with an address. Signals to and from 
all devices were multiplexed on the UNIBUS. PDP-1 1/45 
realized data rates up to 2,500K-words per second with that 
scheme. 

3- Instruction Set 

As previously discussed, the size of the instruction 
set was highly dependent on architecture. Microprogrammed 
minicomputers featured far more powerful instruction sets 
than purely hardware implemented architectures. Most 
minicomputers offered single and double-word manipulation. 
The HP2100A, PD2-11/45 and UYK-20 featured floating-point 
instructions as an option. UYK-20 floating-point 
instruction speeds were medium compared to other 
minicomputers. For example, for a floating-point Add 
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instruction the times were HP2100A: 23.5 usee to 59.8 usee; 
OYK-20: 7.7 usee to 17.4 usee; PDP-11/45: 2.4 usee to 5.5 
usee. 

Bit manipulation capability was extensive on those 
minicomputers designed for process control. For instance, 
the Texas Instruments CP-960A was a bit oriented, rather 
than a word oriented, machine. Some general purpose 
minicomputers like the HP2100A and PDP-11/45 offered several 
bit manipulation instructions (Test and Set, Compare, Reset, 
etc.) . OYK-20 featured those basic bit manipulation 
functions except Test and Set which required two 
instructions - very awkward in a real-time programming 
environment. Byte manipulation was a necessary capability 
for real-time processing, expecially for data communications 
applications. OYK-20 possessed some capability (Load, Load 
and Index, Store, Add, Subtract, Compare, Compare and 
Index) . The use of those byte manipulation instructions was 
necessarily awkward since the OYK-20 was a word oriented 
rather than a byte oriented machine. That is, each 
consecutive address referenced a full word. It was 
necessary to indicate by. setting a bit in a register which 
of the two bytes in the word addressed was desired. Byte 
manipulation instructions were not, however, a common 
feature of commercial general-purpose minicomputers. 

Another feature not commonly found on minicomputers 
was the implementation of trigonometric and hyperbolic 
functions as machine instructions. Through MATHPAC a useful 
set of such functions was available on OYK-20 as an option. 
Some available microprogrammed machines featured extra 
control storage capacity where users could implement such 
functions. 

A capability available on some minicomputers, but 
totally lacking on OYK-20, was memory- to- memory 
instructions. That is, the capability to perform operations 
on data in memory and return the result to memory without 
.first loading the data into a register. Yarian 73 and 
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PDP-11/45 both featured some memory-to-memory capability, 
but in UYK-20 all data had to be first loaded into a 
register to perform further operations. 

• Input/Out put 

The most popular I/O scheme in 1972 minicomputers 
featured a single I/O bus. In a single I/O bus structured 
machine, data transfer was generally controlled by the CP. 
Data rates were slow (300K- to 400K-words per second) . 
Generally a number of peripherals could be interfaced on the 
I/O bus. The Rolm 1602 could support up to 61 devices, but 
the HP2100A only 14.. Varian 73 was also a single I/O bus 
structured machine. Such machines usually featured at least 
one DHA channel. The Varian 73 featured a Priority Memory 
Access (PMA) channel which allowed data transfers up to 
3,300K-words per second when semiconductor memory as 
installed. A typical DM& channel data rate was 1,000K-words 
per second. 

The processor independent IOC featured on the UYK-20 
made that I/O scheme more powerful than found on most 
minicomputers. The IOC acted as an independent processor 
with its own control memory and instruction set. Each group 
of four channels contained its own arithmetic unit and 
registers and so could operate independently once data 
transfer was initiated by the IOC. One drawback was that 
the IOC shared a memory port with the CP. Another was that 
four channels shared an arithmetic unit and registers so 
that all channels of one group had to be of the same type. 
The instruction set implemented in the IOC was minimal. 
Data manipulation had to be performed by the CP. 

Again, the PDP- 11/45 UNIBUS structure was a unique 
approach. Each peripheral device was interfaced to the bus 
through its own independent controller. Thus, every I/O 
channel was a DMA channel. In addition, each device could 
communicate independently with another device. Every device 
on the UNIBUS, including the CP, was assigned a priority. 
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Communications were handled according to priority by a 
UMBOS Priority Arbitration Unit. By that system/ I/O 
transfers were handled indentically to memory accesses. 
Thus, every instruction implemented on the PDP-11/45 could 
be used in an I/O program to manipulate data. 

5. Interrupt Structure 

Some 1972 minicomputers featured a priority 
interrupt structure. As previously discussed, minicomputers 
with stack architecture generally featured multi-level 
interrupt nesting capability. On other machines nesting was 
accomplished by providing storage area for machine status 
for each interrupt line. Two methods of handling interrupts 
were common. The first involved branching to a specific 
memory word assigned to the interrupt, which contained the 
address of the interrupt service routine. The second 
allowed a direct branch to the interrupt service routine. 
The latter method was faster, but required more hardware 
logic. OYK-20 implemented the former scheme. 

On UYK-20, as previously discussed, only three 
storage areas were provided to store machine status (one per 
interrupt class) so that nesting capability was severely 
limited. 

6 . Construction 

The term "modular construction" had different 
connotations with different manufacturers. The most common 
scheme featured a simple backpanel which provided only power 
lines, data and address buses, etc., which were common to 
all printed circuit (PC) card modules. All PC cards were 
the same size and could be plugged into any slot. Circuits 
on a particular PC card related to functional caxagories, 
there being one PC card for the CP, one for memory control 
circuits, one for each memory bank, and one for each I/O 
device interface. HP2100A, Rolm 1602 and Varian 73 ware 
configured in that manner. The PDP-11/45 also was similarly 
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configured, although backpanel wiring was more complex due 
to the ONIBUS structure. PC cards were generally large and 
were structurally reinforced for strength. 

UYK-20 featured an entirely different approach. PC 
card modules were utilized, but cards were small and were 
hardware type oriented rather than functionally oriented. 
For instance, control memory and associated circuitry 
accupied four PC cards, the master clock occupied another, 
interrupt storage another, and each general register set 
(two sets of 16 registers each) occupied a card. The UYK-20 
scheme facilitated the installation of plug-in options that 
were available [App. I], but created a complicated wiring 
situation on the backpanel and greatly increased the number 
of different types of PC cards utilized. The maintenance 
plan where a majority of the PC cards were "throw-away" 
modules (i.e. those cards could be discarded when found to 
be defective) also depended on that scheme. Naturally, a PC 
card containing an entire processor would be too expensive 
to discard. The repairable PC cards in the DYK-20 were 
those few that were large and functionally oriented - Memory 
Array Boards, Memory Control Boards and I/O Interface cards. 
Those generally were inadequately reinforced, tended to 
bend, and were extremely difficult to remove and install. 
Interestingly, the Rolm 1602 featured large functionally 
oriented cards and met all military specification 
requirements including shock and vibration testing. That 
computer was service approved and designated AN/OYK-1 9 (V) . 

A significant achievement by Rolm in the 1602 design 
was a demonstrated MTBF of 11,000 hours. Since the 0YK-20 
experienced significant reliability problems, it would be 
informative to investigate the differences in those two 
computers. It is beyond the scope of this thesis to present 
a detailed analysis of the impact of the design and 
construction of the two machines on their demonstrated 
reliability. Some major points can be made, however. The 
logic design itself was a contributor to UYK-20*s 
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reliability problems. For example, the TAAF program 
conducted at Naval Weapons Center Dahlgren revealed that the 
master clock and certain logic gates in the UIK-20 were 
overloaded* A user reported that the HIL-STD- 188C 
asynchronous, serial I/O interface card was defective in 
that the channel would interrupt on both leading and 
trailing edges of an interrupt signal pulse. Those were 
basic logic design problems and would directly contribute to 
module failures. Construction and reinforcement of larger 
PC cards was inadequate in UYK-20. With frequent handling 
such cards suffered broken components, jumper wires, printed 
circuit runs and connection pins. All such occurrences 
created circuit failures which lowered MTBF . In a complex 
backpanel wiring situation, lack of adequate quality 
assurance measures could allow wiring errors to pass 
unnoticed. Such errors could appear as circuit failures 
under troubleshooting procedures utilizing diagnostic 
software. Over the three years after contract award, UNIVAC 
had corrected many of those sorts of problems. let the MTBF 
had risen to only 1500 hours. The reason for that may lie 
in the selection and integration of components. The ability 
for a manufacturer to control the quality of components used 
in producing computers would directly impact on reliability. 
In producing the 1602, Rolm Corporation had that control. 
Most components in QYK-20 were procured under military 
specifications (with the exception of integrated circuits) . 
Such components must be procured from a Qualified Parts List 
(QPL) vendor under military specification control. In that 
situation DNIVAC had no control over component quality. 
Hardware engineers interviewed generally agreed that many 
components procured under military specifications probably 
exhibited MTBF 1 s in the hundreds of hours. 

7. Supp ort Software 

It is beyond the scope of this thesis to present a 
detailed analysis of the available minicomputer support 
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software in 1972. Some comments can be made about 
availability, however. As indicated in Apps. J through M , 
commercial minicomputers generally featured a complete set 
of software. In most cases a minicomputer was upward 
compatible with earlier models, so that each inherited a 
package of well tested and fully documented support 
software. New software modules could be added at leisure to 
take advantage of the added capabilities of the more 
advanced machine. 

Most software engineers interviewed agreed that 
adequate operational testing was difficult to achieve. 
Complete debug of a software module depended on extensive 
use in the field. Naturally, any software package inherited 
from a market-tested computer had that advantage. 

The 'UYK-20 computer did not have that advantage. 
Although upward compatible with the AN/UYK-15(V) [App. D], 
that machine did not possess a complete package of support 
software and had not had extensive use. Support software 
for UYK-20 was developed during the three years following 
contract award. As of mid-1976 the CMS-2M compiler and 
SDEX-20 real-time executive were still in the "user debug" 
stage. All software was still receiving enhancements to 
upgrade capability as funds became available. 

The foregoing material in this thesis has discussed 
the events which occurred in the AN/tJYK-20 DPS acquisition 
history and the technical advantages and drawbacks of the 
system. The final section in this chapter will discuss the 
impact of those events, advantages and disadvantages on the 
users and their tactical system development efforts. 



C. IMPACT OF AN/UYK-20 DPS ON DEVELOPMENT OF USER SYSTEMS 



The events of the three 
which have been referred 
significant impact on the 



years after contract award, 
to a "growing pains", had a 
efforts of users to develop 
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tactical systems utilizing OYK-20 as a system component. 
This section will discuss the various ways which that system 
component aided or complicated those development efforts 
during the period mid-1973 to mid-1976. 

1 . Establi shment of AN/UYK-20 as a Sta nda rd 

The implications of establishing a "standard" system 
component were discussed in Chapt. II, Sect. B. For those 
programs well into development with another minicomputer and 
/or programming language, the impact on acquisition cost and 
schedule to switch to UYK-20 was significant. One project 
reported a two year schedule slip and software costs of 
$350,000 to $400,000 to reprogram for the UYK-20. Since 
that system involved primarily data-handling, only limited 
processing power and core memory capacity were needed. A 
lower cost processor with UK-words of memory and unit cost 
of $15,000 was replaced by a minimum configuration UYK-20 
with 8K-words of memory and unit cost of $24,000. Another 
project reported a four to five month slip and $4 00,000 to 
$500,000 cost to reprogram with CMS-2M, the standard 
high-level language. 

The trade-off for those projects was to lower 
life-cycle costs through savings in ILS costs, training 
costs, etc. as previously discussed. Unfortunately, the 
immediate concern was always initial acquisition cost, 
schedule, and performance. While life-cycle cost was given 
lip-service, a project's success was ultimately measured by 
success in those three areas. Thus, imposition of the 
standard on a system well into development impacted directly 
on the measure of the project's success. 

Because of the necessity to identify firm 
requirements for UYK-20 production units, and to obtain OSMN 
funds through the surcharge scheme, NAVELEX was forced to 
require those projects to switch to UYK-20. 

The technical drawback of adopting a standard was 
that the UYK-20 might not be specifically suited for a 
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particular application. An example might be an engine 
monitoring and control system where a powerful bit 
manipulation capability was needed. That project would be 
required to use UYK-20 regardless of the minimal bit 
manipulation capability. Interestingly, no project 
personnel found the UYK-20 totally unsuited for their 
application. It has been reported that as of mid- 1976 over 
100 projects were utilizing DYK-20. Tasks included the 
following diverse sorts of requirements: 

* Message Processing Systems 

■ Low memory capacity (8K- to 16K-words) 

■ Low computing power 

■ High I/O capacity (12 to 16 channels) 

■ High data rates 

* Navigational Systems 

m Medium memory capacity (16K- to 32K-words) 

■ 32-bit (double word) I/O transfer 

■ 32-bit data manipulation 

■ Floating-point trigonometric and hyperbolic 
functions 

■ High accuracy (up to 24-bits per data word 
preferred) 

■ Low I/O capacity (4 to 8 channels) 

* Signal Analysis Systems 

■ Large storage capacity (65K-words of memory plus 
high-speed mass storage device (disk) on DMA 
channel 

■ Multi-programming capability 

■ Powerful mathematical capability 

■ High throughput (instruction execution rate) 

■ High I/O data rates 

m High I/O capacity (8 to 16 channels) 

* Target Tracking and Fire Control Systems 

■ 32K- to 65K-words of storage capacity 
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■ 12 to 16 I/O channels 

■ Mass storage device (disk) on DMA channel 

■ Floating-point and trigonometric functions 

■ High throughput (instruction execution rate) 

■ Special user functions implemented through 
Microgrowth 



It was a significant accomplishment, and spoke well for the 
DBG specification, that (JYK-20 was able to handle those and 
many other diverse tasks. 



The conclusion was that few projects were severely 



impacted by imposition of a standard minicomputer. 
Unfortunately, that statement could not be made about 
OYK-20, the computer that became the standard. 



Users generally found the UYK-20 architecture 



powerful enough for their needs. Local Jumps, Load Multiple 
and Store Multiple instructions not common on minicomputers 
were very useful. The availability of 32 general registers 
was a powerful programming aid. I/O structure was versatile 
and powerful with the processor independent IOC. Certain 
attributes caused some inconvenience, however. 



The awkward byte addressing scheme discussed in the 



previous section would add an additional instruction to byte 
manipulation operations in order to set the upper/lower byte 
indicator. Execution time for the byte operation would be 



doubled. One solution was to write self-modifying code, to 
modify the byte manipulation instructions "on-the-f ly" . 
This created programs which were very hard to debug. Also, 
such code was non- reentrant ; i.e. it could not be reused 
without reloading the original program from an external 
device, and it could not be shared in a multi-programming 
environment. 



Lack of memory-to-memory instructions added Load and 



2. 




increased about 50% and program 



storage 



requirements 
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Store instructions to those operations because of the need 
to put the data in registers. About 1.5 usee was added to 
the execution time for memory-to-raemory operations/ and 
program storage requirements were tripled. Lack of a Test 
and Set instruction (that operation required two 
instructions in UYK-20) could cause major problems. If an 
interrupt occurred between the two instructions, which 
changed the value that was being tested, then the test 
already performed was invalid. The routine executing the 
Test and Set instructions would not be aware of the change 
and would proceed on the basis of the original test results 
when the interrupt finished processing. The solution was to 
lockout interrupts before executing the Test and Set 
instructions and to restore interrupts after completing the 
Test and set. That solution added two to four instructions 
and 3.3 to 4.8 usee to a Test and Set operation. 

There were no absolute compare instructions in 
UYK-20. When comparing two words, the most significant bit 
would always be considered the sign. To compare a 16-bit 
absolute word a double-word operation was needed. Time and 
storage requirements were thus again added to the user 
program. 

The sum total of those sorts of deficiencies 
significantly decreased throughput and increased storage 
requirements. The solution was to implement the missing 
capabilities in the User Microgrowth area of control memory. 
Such a development effort had to be user funded, however. 
As an example, one activity received a quotation of $50,000 
to implement four instructions in Microgrowth: 

* Increment and Store Memory 

* Literal Add to Memory 

* Add to Memory 

* Literal Store to Memory 
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In addition, an extra $1,000 was added to the price of each 
production unit. Many projects preferred to suffer the 
inconvenience rather than pay the price. 

For those systems with large storage requirements 
and a large number of tasks which could be performed 
simultaneously, the lack of proper tools to implement 
multi-programming was a serious drawback. Although page 
registers existed, there was no privileged instructions or 
memory protection with which to implement sophisticated page 
swapping algorithms. The alternatives required more time 
and tied up valuable storage space, both expensive 
commodities in time-critical, real-time applications. 

The storage capacity problem could have been 
relieved in some cases if a provision to expand memory 
beyond 65K-words had existed. Alternatives involved adding 
additional UYK-20 1 s to the system, which was expensive if 
the additional processing power was not also needed, or 
adding a mass storage device on the DMA channel, which would 
often not meet speed requirements. To solve the dilemma in 
one case, a semiconductor memory disk emulator was conceived 
which would interface to the computer through the DMA 
channel. Ability to utilize semiconductor memory in place 
of core memory would have alleviated some similar problems 
if that capability had existed. 

A capacity problem also plagued some projects in the 
I/O area. Although the processor independent IOC provided 
powerful I/O capabilities , only 16 channels were available, 
with the type configuration constraints previously 
discussed. To get more capacity required multiplexing on a 
channel, which slowed down th data rate, or adding more 
UYK-20's to the system. 

Certain I/O configurations would have benefited from 
complete independence of the two sides of a duplex channel. 
However, both sides shared registers and could not be 
cleared independently. Several users stated the need to 
write extra routines to prevent losing data on one side if 
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the need arose to clear the other side of a channel. 

A characteristic of serial, synchronous interface 
channels was that the first few characters transmitted were 
"garbage" due to the need to establish synchronization. 
This situation could not be tolerated on a radio (RF) data 
channel where good data would be lost. The solution was to 
alter the RF Data Channel hardware. 

A common complaint from development programmers was 
the inadequacy of the Maintenance Panel for software 
debugging. Lack of I/O status indicators and 
multiple-register displays were cited as drawbacks. The 
maintenance panel had too much capability for hardware 
troubleshooting, but not enough for program debug. A 
solution would have been to reduce the capability of the 
maintenance panel and provide a plug-in software debug 
panel. The lack of I/O status indicators was a serious 
problem since, with the IOC independent of the processor, 
there was no way to determine if an I/O transfer was 
actually taking place after it was initiated. 

Lack of interrupt nesting capability was a major 
concern to development programmers. Care had to be 
exercised so that multiple interrupts occuring in one class 
would not store over the original machine status, thus 
preventing a return to the interrupted routine. The 
solution was usually to lock-out other interrupts, which 
virtually nullified the priority interrupt capability. 
Real-time programs were generally interrupt driven, thus, 
loss of priority interrupt capability was a serious 
drawback. 

The awkwardness of using the indirect addressing 
capability caused some programmers to abandon its use in 
favor of direct addressing with indexing. 

3 . Availability of Support Software 

The support software for the AN/UYK-20 DPS was slow 
in coming. Those programs in development in late-1973, 
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which were forced to switch to UYK-20, had only a limited 
capability assembler. As a result, many created their own 
program development capability. Doing that added to the 
time and cost of a system since operational program 
development would cease while programmers wrote monitors, 
assemblers, editors, debug routines, etc. As an example, 
the cost of developing an assembler was $5,000 to $100,000 
depending on its capability. It was cheaper and faster to 
write your own, however, than to wait for the Level I and 
Level II systems to be released and debugged. 

The late delivery of CMS-2M (early- 1975) caused 
two-fold problems. Many early operational programs for 
UYK-20 had to be written in assembly language. Since it 
took the same time for a programmer to code one line of 
assembly language as to code one line of a high-level 
language (with a ratio of about six assembly language 
instructions to one high-level language instruction) , the 
cost was significant. Those projects which elected to start 
development with another high-level language (usually 
FORTRAN) faced the prospect of reprogramming in CHS-2 M when 
that compiler became available. 

The whole question of program development facilities 
for a minicomputer is worth some discussion. It was 
generally not possible to configure a small computer for 
efficient program development. Level II Operating System, 
which was self- hosted on the UYK-20, could support only one 
programmer at a time. Although both interactive and barch 
mode's were provided, compile times were slow and debug 
facilities were minimal. What was generally needed was a 
larger computer with a time-sharing monitor so that several 
programmers could work simultaneously. An ideal system 
would feature cross-assemblers and compilers to generate 
object code for the small computer. Adequate memory, disk 
storage and a number of program development aids such as a 
text editor, debug utilities, data conversion routines, etc. 
would be a necessity. A program to emulate the small 
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computer would be useful for initial debugging of 
operational software. 

A few activities which were to do extensive program 
development for the UYK-20 did create such systems. The 
Electromagnetic Systems Laboratory in Sunnyvale set up a 
tine-sharing system on a Hewlett Packard 3000 computer. The 
system featured a direct link to a UYK-20 computer via a 
special intercomputer I/O channel. Source code generated on 
the HP3000 could be loaded directly into the UYK-20 for 
assembly or compiling. The Autonetics Division of North 
American Rockwell set up a similar system based on a 
PDP-11/45 computer. FCDSSA San Diego developed the 
CMS-2Y(20) compiler for use on an AN/UYK-7 computer under 
the SHARE/7 time-sharing system as an aid to their software 
development and maintenance efforts. 

Such systems were understandably costly to set up. 
In addition, the hardware and associated software to 
interface the system directly to a UYK-20 had to be 
developed in-house. The project sponsoring the development 
had to provide the funds. The dilemma facing the project 
manager was whether it was more cost effective to fund a 
program development facility or to provide a self- hosted 
system for the UYK-20 and suffer the inefficiencies. As an 
example, the price of a self-hosted system with Level II and 
CMS-2M would be about $150,000 including peripherals. At 
the other end of the price spectrum, the UYK-7 hosted system 
would cost about $800,000. Commercial systems would be 
priced in between depending on capability. 

To provide program development facilities and save 
projects the cost of support software and peripherals, a 
System Design Laboratory (SDL) was conceived by the Naval 
Electronics Laboratory Center. That was a commercial 
computer based time-sharing system with cross-assemblers, 
compilers and an emulator for UYK-20. The systea could be 
accessed via the ARPANET, a commercial nationwide computer 
network linked by leased telephone lines. Anticipated 



75 



drawbacks of that scheme were possible demand beyond the 
system capacity, and the fact that classified programs could 
not be developed on the system. In fact, the majority of 
projects depended on the self-hosted system. The 
non-availability of a well-tested, complete, self-hosted 
program development system at the outset impacted 
significantly on both cost and schedule of projects. 

4 . Support Software Capabi litie s 

It is beyond the scope of this thesis to present a 
detailed analysis of the impact of support software 
capabilities on program development. However, certain 
points brought out by development programmers are worth some 
discussion. 

A dynamic debug capability was needed under Level 
II. As of mid-1976 the development of this capability was 
planned, but funds were not available. Dynamic debug 
capability would allow programmers to perform analysis on an 
executing program without interfering with its execution. 

CMS-2M listings of source code and object code were 
not produced side-by^side, making cross-referencing awkward 
and time consuming. 

CMS-2H depended on the trigonometric and hyperbolic 
functions provided through MATHPAC. Accuracy provided was 
insufficient in some applications. The large variety of 
useful functions and routines developed for a well-used 
language like FORTRAN were not available with CMS-2M. 
Because that language anticipated restricted usage, such a 
library of routines would never be created, forcing the 
development programmer to write his own routines when 
needed. In recognition of this problem, the User's Group 
Software Directory and the Software Repository mentioned in 
Chapter III were an attempt to prevent redundant development 
of such routines. 

CMS-2M was not aa optimizing compiler. Because many 
operational programs are time-critical and have large 
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storage requirements, it would have been useful to have an 
optimizing version of the CMS-2M compiler to minimize use of 
those assets. 

Like any general purpose real-time executive, 
SDEX-20 required too much core and system overhead (time 
spent in executing the executive software) to be widely 
useful. Those applications with time-critical routines and 
large storage requirements were forced to write their own 
real-time monitors. By writing an executive in-house it 
could be optimized for the particular application, thus 
minimizing storage and overhead. Many programmers felt that 
a general purpose real-time executive would be useful if the 
source code were available to programmers as a reference to 
aid in writing their own. The low usage, of SDEX-20 raised 
the question of the cost-effectiveness of supplying that 
type of support software. 

5 . A va ilability of Peripherals 

The peripherals problem is actually divided into two 
catagories: peripherals for program development, and 
peripherals for tactical systems. Up to mid- 1976 no 
standard militarized peripherals were available for 
purchase, except keyboard/printers and paper tape 
reader/punches which had been in existance for several 
years. Those units ware generally too large for a 
minicomputer installation. Even with the introduction of 
the Alphanumeric Display Device (ADD) and the Cartridge 
Magnetic Tape Unit (CMTU) in mid-1976, important peripherals 
were still lacking, such as a magnetic tape unit 
(reel-to-reel), a disk storage device, and a graphics 
display terminal. Projects were forced to fund 
militarizaioh of their own peripherals, which created the 
same sort of proliferation problem encountared with 
minicomputers in the early 1970* s. 

During the early production period in late-1973, 
only UNIVAC peripherals could be interfaced with the UYK-20 
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for program development. Those peripherals were generally 
too large and expensive for a minicomputer system, so 
projects began acguiring their own. Costs of procuring 
peripherals included development of device software modules 
to interface with the DYK-20 operating systems. The 
acquisition of peripherals to be used for program 
development was costly, especially since those peripherals 
would in general not be used in the tactical system itself. 
Projects were wise to retain a UYK-20 system with 
peripherals configured for program development to be 
provided as Government Furnished Equipment (GFE) for future 
development efforts. 

6 • Hardware and Software Reliability and 

Main tai n abili ty 

The acute quality and reliability problems 
experienced in the AN/UYK-20 DPS were reported in Chapter 
III. It was those problems that had the most profound 
impact on user development efforts. 

The programs developing in mid- to-late- 1 973 were 
forced to use Functional Demonstration Models (FDM* s) and 
Advanced Production Engineering Models (APE's) in order to 
meet development schedules. That hardware was essentially 
not ready for release. The numerous deficiencies and 
failures caused significant down time. Projects were forced 
to purchase two computers and cannabilize one to keep the 
other running. Early production units had similar problems. 
Software debugging on faulty hardware was a difficult and 
time-consuming task. One activity reported expending three 
man-months of labor trying to debug a program when the 
problem was actually in the interrupt hardware. 

Efforts to troubleshoot faulty hardware were 
hampered by faulty spares in the spare parts kits. The kits 
were expensive ($13,000 each) so that project managers were 
unwilling to purchase sufficient numbers. Project personnel 
estimated that one spares kit per computer was necessary to 
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ensure parts availability. Memory Array Boards, which 
experienced very high failure rates, were repairable modules 
and were not included in the spares kits. Since the time to 
ship the repairable modules back to UNIVAC for repair and 
return was running six to eight weeks, activities were 
forced to purchase extra Memory Array Boards (at $1,300 
each) to minimize down time. 

It was more timely and cost effective for some 
activities, like NESEC San Diego, to do their own hardware 
trouble-shooting and repair, rather than call in UNIVAC 
engineers. The diagnostic software and documentation was 
not well suited to this effort. The diagnostic routines 
could isolate circuit board failures, but not design 
problems which plagued the earlier machines. Activities 
turned to logic circuit diagrams, but found that those also 
contained errors. It was difficult to maintain accurate 
up-to-date files of logic circuit diagrams since no formal 
system existed for procuring them. 

Early releases of the support software had many 
errors. User activities attempting to debug the software 
were hampered by inadequate and erroneous documentation. 
Source code was not available initially to aid in their 
efforts. After repeated demands the source code for the 
operating systems was made available, but code for the 
compilers was withheld as a matter of proprietary 
information. Most software engineers interviewed expressed 
the opinion that the support software source code, including 
compilers, should be purchased outright by the Navy so that 
it could be made available to users. That was especially 
true when the support software contained so many errors and 
the documentation was inadequate. In many cases programmers 
had to resort to the source code to determine the details of 
system software operation. One activity reported that it 
was once forced to reprogram to take advantage of an 
assembler capability which was not mentioned in the 
documentation. A basic problem with software documentation 
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was that no detailed discussions of software philosophy were 
presented. Adding the problems in the software on top of 
problems in the hardware made an extremely difficult 
situation for programmers attempting to debug operational 
software. 

7. Lack of Dedica ted Appropriated Funds to Su£oort the 
AN/OYK-2 C DPS 

It is significant that a majority of problems were 
corrected when usage was sufficient to isolate those 
problems. Given time the support software became available. 
Given time the standard peripherals would be available. If 
NAVELEX could have waited until the system was adequately 
tested before release, much of the inconvenience caused to 
users would have been eliminated. The reason that NAVELEX 
could not wait was lack of funding. It was necessary to 
identify specific requirements for production units and to 
receive orders for the system in order to get the surcharge 
that paid for project support. NAVELEX was thus forced to 
require the use of the system before it was ready. An 
obvious solution was to wait until funding for the entire 
acquisition cycle was reasonably assured (another year at 
best) . Then wait until the system was complete, including 
software and testing, before releasing it (another two to 
three years) . Of course, a three to four year delay would 
have brought proliferation of minicomputer types in the Navy 
inventory to an unacceptable level. Some of that delay 
might have been saved by purchasing a "market-tested" 
computer system, then militarizing it. At least the 
reliable commercial equivalent would have been available for 
use in development until the militarized version was 
available. Certainly computer systems existed which could 
meet Navy performance requirements. 

The lack of dedicated funds has thus been identified 
as the prime-mover in many events in the history of the 
AN/UYK-20 DPS acquisition. The final chapter will summarize 
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and present some recommendations which might prove useful in 
future tactical processor acquisitions. 
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V. SUMMARY, CONCLUSIONS AND RECOMMENDATIONS 

In 1972, when proliferation of minicomputer types in the 
Navy inventory was perceived to be a significant problem, 
the Tactical Digital Systems Office (TADSO) of the Naval 
Material Command (NAVMAT) conceived the procurement of a 
standard minicomputer. Use of that minicomputer was 
required in all tactical systems requiring a small computer 
unless sufficient justification was given to use a different 
computer • 

Although no funds had been appropriated for such a 
procurement, NAVMAT, with the approval of the Chief of Naval 
Operations (CNO) , proceeded to initiate the procurement 
action by r eprogramming a minimum of Research, Development, 
Test and Evaluation Navy (RDT&EN) appropriated funds from 
anticipated user projects. A Design Review Group (DRG) was 
convened, and a fairly restrictive technical specification 
was drawn up. With th« exception of an assembler, support 
software requirements were missing entirely from the 
specification. At that point the Navy was procuring 
one-half of a minicomputer system with no funds appropriated 
for future support. The necessity to get support funds 
forced NAVMAT to require projects still in their development 
phase to include the standard minicomputer immediately in 
their program and to assess a surcharge on purchases of 
standard minicomputer hardware and software. 

The contract award went to the lowest bidder, UNIVAC 
Defense Systems Division of Sperry-Rand Corporation. The 
DRG specification appeared to be influenced by the ONIVAC 
design philosophy, owing to the large number of ONIVAC 
computers in the Navy inventory. 

Although the original acquisition strategy intended that 
the minicomputer system be a militarized off-the-shelf 
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commercial system, UNIVAC won the competition with a new 
design that had never been in production and was not upward 
compatible with any well-established family of computers. 

In order to meet user project development schedules, the 
first Functional Development Models (FDM) (non-militarized 
prototypes) were delivered within 120 days after contract 
award and the first Advanced Production Engineering Models 
(APE) (militarized prototypes) within nine months after 
contract award. Although the hardware design held the 
potential for good capabilities in a minicomputer, the 
FDM's, APE's and early production units were inadequately 
tested and debugged. Reliability was very low and 
maintainability suffered from inadequate diagnostic 
programs, poor documentation, faulty spares, and excessive 
turnaround time on repairable modules. 

Initially software was non-existent; when released it 
was inadequately tested and debugged. User efforts to use 
the software were hampered by poor documentation. 

Thus, lack of dedicated funding forced users to utilize 
the standard minicomputer as a system component before it 
was ready. The result was significant labor costs to cope 
with the problems and increased risks in the development of 
operational programs. 

It was mid-1976, three years after contract award, 
before the system was sufficiently reliable and possessed 
adequate support software to be considered a viable system 
component in a developing tactical system. 

It must be recognized that follow-on standard tactical 
digital processors may not be minicomputers. Perhaps the 
design will be a distributed microprocessor system or some 
architecture not yet conceived. The rapid advance in the 
state-of-the-art of digital processors makes the 
possibilities endless. The events connected with the 
standard minicomputer acquisition do foster, however, some 
conclusions and recommendations pertinent to future 
acquisitions of tactical digital processors, regardless of 
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architectural philosophy. 



1. The life-cycle cost and logistics support, 
considerations make adoption of standards necessary. 

2. The decision as to how often to reprocure a standard 
involves a tradeoff between two alternatives: (1) 
reprocuring rapidly enough to keep up with advances in the 
state-of-the-art, and (2) producing a particular standard 
long enough to maximize the economic benefit of large-scale 
production. The tolerance of tactical system development 
engineers for using an "old" standard must also be taken 
into account. That decision must be made on the basis of 
factors such as availability of funds and how well the 
current standard is performing at the time. 

3. The primary goal of the standard minicomputer 
acquisition strategy was to stem the proliferation of 
minicomputer types in the Navy inventory. That goal was 
accomplished at the expense of significant adverse impact on 
the costs and schedule of user projects. It is this 
author's opinion that the "cost" of the adverse impact 
outweighed • the benefit of minimizing proliferation. It 
should be the primary goal of future tactical digital 
processor acquisitions to deliver a highly reliable system 
complete with support software and accurate documentation. 
That would be simply applying current systems engineering 
management and Integrated Logistics Support policies. 

4. The standard minicomputer procurement was totally 
dependent on user projects for both development and 
operational support funding. That fact was the underlying 
reason why projects were forced to use the system before it 
was ready, accounting for most of the events which impacted 
adversely on those user projects. The availability of both 
RDTSEN and O&MN funding for a standard tactical digital 
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processor acquisition should be reasonably assured prior to 
contract award. Based on experience with the standard 
minicomputer acquisition, contract award should be planned 
for two to three years prior to required delivery of the 
militarized version to the fleet. 

5. Since it would be desirable to minimize the time 
between contract award and delivery to the fleet, the 
acquisition strategy should strongly consider procurement of 
an off-the-shelf, market-tested system which exhibits a 
strong heritage from a successful family of processors. 
Availability of software should be a major consideration. 
It is this author*s opinion that the strong competition in 
the digital equipment industry assures that new commercial 
systems push the state-of-the-art while at the same time 
exhibiting reliable hardware and software performance. The 
strategy just suggested should thus suffer minimal risk of 
early obsolescence. This strategy would also insure the 
immediate availability of FDM's for use in development. 

6. Award of contract in the standard minicomputer 
procurement was based on two factors, (1) technical 
responsiveness and (2) lowest price proposal. Such a 
strategy precludes consideration of which proposal presents 
the best reliability and performance for the price. Future 
acquisition strategies should require a fully negotiated 
procurement based on a performance specification. Such a 
strategy would give the Source Selection Evaluation Board 
the flexibility to consider both design and price. 
Proposals offering market-tested systems could be weighted 
heavily since such systems have usage data to prove 
reliability and performance. 

7. Despite the fact that a pre-award survey found all 
companies submitting proposals to be responsive, the winner 
experienced immediate and severe quality assurance problems. 
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Those QA problems had a profound impact on user development 
efforts. Future pre-award surveys should firmly establish 
the potential contractors 1 abilities to produce a reliable 
product. Careful evaluation of quality control standards 
should be made to assure that those standards will insure 
delivery of a reliable product. 

8. The Requirements, Indefinite Delivery contract awarded 
in the standard minicomputer acquisition was. well-suited as 
a production contract and should be utilized in future 
procurements of standard equipment. 

9. The imposition of military specifications on a 
commercial design creates some risk in the development area. 
Future acquisition strategy should consider awarding a cost 
type development contract for the militarization effort. 
Funds permitting, the award of such a contract to several 
companies would permit a "fly-off 1 , ensuring competition for 
the production contract. 

10. As tactical digital processors become smaller due to 
advances in Large Scale Integration techniques, the need for 
non-self-hosted program development facilities becomes more 
important. Future acquisitions of tactical digital 
processors should consider award of a separate fixed-price 
contract for a program development system to support the 
standard digital processor. Certain digital equipment 
companies specialize in design, integration, and production 
of such specialized systems from off-the-shelf components, 
so that adequate competition should exist for such a 
procurement. 

11. The maintenance and control panels on the AN/UYK-20 
computer did not provide adequate capabilities for software 
test and debug. Future systems should include a plug-in 
software debug console to provide this capability. 
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12. A generalized real-time executive may occupy too much 
core, and require too much system overhead to be widely 
useful in a tactical system environment. Such software 
could be better optimized in designs tailored for the 
specific application. Future acquisitions should not 
include a standard real-time executive with the support 
software, but should provide some means (such as the 
Software Repository) by which projects are made aware of 
such software developed by other users. 

13. Software development engineers interviewed stated that 
source code for the various support software, including 
assemblers and compilers, was a useful tool to aid in 
debugging operational programs. Knowledge of the source 
code would allow the developer to determine the exact 
operation of the software and the philosophy behind its 
design. Future acquisition strategies should include 
outright purchase of the data rights to all software as well 
as hardware so that source code may be supplied to users. 
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APPENDIX A 
AN/UYK-7 SYSTEM DESCRIPTION 



Manufacturer 

Construction Standard 

Maximum Physical Dimensions 

Maximum Weight 

Maximum Power Consumption 

Architecture 

Word Size 

No. of Registers 

Inst. Execution Time 

Add/Sub/Load 

Multiply 

Divide 
Microprogrammable 
Technology 
Privileged State 
Stack 

Main Memory 

Maximum Size 

Speed 

Word-size 

Memory Parity Checking 
Memory Write Protect 
Technology 
Multiporxed 

Instruction Set 

Double Precision 
Byte Manipulation 
Bit Manipulation 
Floating Point 
Math/Trig Functions 
Negation 

Arithmetic Complement 
Stack Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging Hardware 



ONIVAC 

MIL-E-16400 

4 1"Hx24"Dx20"W 

527 to 1,139 lbs. 

1,720 to 6,000 watts 



32-bits 

8 or 16 (accumulators) 

6.5 usee 
10.0 usee 
17.0 usee 
No 

Third Generation/MSI 

Yes 

No 



256K-words (16K/module) 

1 . 5 usee 

32-bits 

No 

Yes 

Magnetic Core 

8 ports/16K module 



Yes 
Yes 
Yes 

Hardware 
Software 

One's Complement 
One's Complement 
No 



262K-words 
Jiulti-level 

7 or 14 index registers 
No 
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I/O Controller 

No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 

Maintenance/Control Panel 
Location 

Multi-register displays 

Initial Program Load 

Reliability S Maintainability 
MTBF 
MTTR 

Diagnostic Programs 

Modular Building Blocks 

Support Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug Routines 
Operating Systems 
Real-Time OS 

Interrupts 

Priority Structure 
Nesting Capability 



16 

Serial/Parallel 
167,000 words/sec 
Yes 



Remote 
No 

Firmware 



Unknown 

15 minutes 

Firmware/Software 

Yes 



Yes 

FORTRAN/CMS -2 

Yes 

Yes 

Yes 

Yes 

SHARE/7 
Yes 



Yes 
No 
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APPENDIX B 
STANDARD MINICOMPUTER SPECIFICATIONS 



Manufacturer 

Construction Standard 

Maximum Physical Dimensions 

Maximum Height 

Maximum Power Consumption 

Architecture 

Word Size 

No. of Registers 

Inst. Execution Time 

Add/Sub/Load 

Multiply 

Divide 
Mic reprogrammable 
Technology 
Privileged State 
Stack 

Main Memory 

Maximum Size 

Speed 

Word-size 

Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 

Instruction Set 

Double Precision 
Byte Manipulation 
Bit Manipulation 
Floating Point 
Math/Trig Functions 
Negation 

Arithmetic Complement 
Stack Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging Hardware 



MIL-E-16400 
26"Hx24"Dx19"W 
220 lbs. 
1,000 watts 



16-bits minimum 

4 expandable to 16 (general) 

1.2 usee 
9.0 usee 
20.0 usee 
Yes 

3rd generation/MSI 
Not req'd 
Not req'd 



65K-words (SK min.) 

1.2 usee p.O usee effective) 

16"bits minimum 

Optional 

Not req'd 

RAM, non-volatile 

Two (Processor/IOC) 



Yes 
Yes 

Not req'd 
Not req'd 
Not req'd 

One's and Two's Complement 
One's or Two's Complement 
No 



65K-words 

To at least one level 
All general registers 
Yes 
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I/O Controller 

No, of Channels 
Types of Channels 
Maximum Data Bate 
Processor Independent 

Maintenance/Control Panel 
Location 

Multi-register displays 

Initial Program Load 

Reliability & Maintainability 
MTBF 
MTTR 

Diagnostic Programs 

Modular Building Blocks 

Support Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug Routines 
Operating Systems 
Real-Time OS 

Interrupts 

Priority Structure 
Nesting Capability 



16 

Ser/Par/DMA 
1 90K-words/sec 
Yes 



Optional 
Not req'd 

Hardware or Firmware 



2000 hours 
15 minutes 
Yes 

Yes 



Yes 
Not 
Not 
Not 
Not 
Not 
Not 
Not 



req • d 
req *d 
req • d 
req • d 
req 1 d 
req 1 d 
req • d 



Yes 
Four 



levels-one per group 
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APPENDIX C 
CP-642B SYSTEM DESCRIPTION 



Manufacturer 

Construction Standard 

Maximum Physical Dimensions 

Maximum Weight 

Maximum Power Consumption 

Architecture 

Word Size 

No. of Registers 

Inst. Execution Time 

Add/Sub/Load 

Multiply 

Divide 
Microprogrammable 
Technology 
Privileged State 
Stack 

Main Memory 

Maximum Size 

Speed 

Word-size 

Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 

Instruction Set 

Double Precision 
Byte Manipulation 
Bit Manipulation 
Floating Point 
Math/Trig Functions 
Negation 

Arithmetic Complement 
Stack Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging Hardware 



ONIVAC 
MIL-E-16400 
72"Hx37"Dx38"W 
2,400 lbs. 
2,000 watts 



30-bits 

3 (accumulators) 

8-12 usee 
8-12 usee 
8-12 usee 
No 

Discrete Components 

No 

No 



32K to 262K-words 

4 usee 

32-bit 

No 

No 

Magnetic Core 
No 



Yes 
Yes 
No 

Software Implemented 
Software Implemented 
One's Complement 
One's Complement 
No 



32K-words 
No 

7 Index Registers 
No 
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I/O Controller 

No. of Channels 16 

Types of Channels Parallel 

Maximum Data Rate Unknown 

Processor Independent No 

Maintenance/Control Panel 

Location Front of Cabinet 
Multi-register displays Yes 

Initial Program Load Firmware 

Reliability & Maintainability 

MTBF 1500 hours 

MTTR Unknown 

Diagnostic Programs Yes 

Modular Building Blocks No 

Support Software 

Assemblers Yes 

Compilers CS-1 

Loader Yes 

Editor Yes 

Librarian Yes 

Debug Routines Yes 

Operating Systems No 

Real-Time OS No 

Interrupts 

Priority Structure Yes 

Nesting Capability No 
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APPENDIX D 
AN/UYK-15(V) SYSTEM DESCRIPTION 



Manufacturer 

Construction Standard 

Maximum Physical Dimensions 

Maximum Weight 

Maximum Power Consumption 

Architecture 

Word Size 

No. of Registers 

Inst. Execution Time 

Add/Sub/Load 

Multiply 

Divide 
Microprogrammable 

Technology 
Privileged State 
Stack • 

Main Memory 

Maximum Size 

Speed 

Word-size 

Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 

Instruction Set 

Double Precision 
Byte Manipulation 
Bit Manipulation 
Floating Point 
Math/Trig Functions 
Negation 

Arithmetic Complement 
Stack Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging Hardware 



ONIVAC 

MIL-E-16400 

2 1"Hx17"Dx19"W 

200 lbs. 

500 watts 



16-bits 

64 (general) 

0.75 usee 
3.8 usee 
3.8 usee 
No 

Third Generation/MSI 

No 

No 



65K-words 

0.75 usee 

18-bits 

Yes 

Yes 

Magnetic Core 

Four ports/16K-word bank 



Yes 
Yes 
Yes 

Software Implemented 
Hardware Implemented 
Two's and One's Complement 
Two's Complement 
No 



65K-words 
No 

All General Registers 
No 
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I/O Controller 

No, of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 

Maintenance/Control Panel 
Location 

Multi-register displays 

Initial Program Load 

Reliability & Maintainability 
MTBF 
M?TR 

Diagnostic Programs 

Modular Building Blocks 

Support Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug Routines 
Operating Systems 
Real-Time 05 

Interrupts 

Priority Structure 
Nesting Capability 



16 

Ser/Par 

19 OK- words/sec 
Yes 



Front of Cabinet 
No 



Firmware 



2000 hours 
15 minutes 
Firmware/Software 

Yes 



Yes 

Unknown 
Yes 

Unknown 
Unknown 
Unknown 
Unknown 
Unknown 



Yes 

Four levels-one per class 
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CP-890 



APPENDIX E 

SYSTEM DESCRIPTION 



Manufacturer 

Construction Standard 

Maximum Physical Dimensions 

Maximum Weight 

Maximum Power Consumption 

Architecture 

Word Size 

No. of Registers 

Inst. Execution Time 

Add/Sub/Load 

Multiply 

Divide 
Microprogrammable 
Technology 
Privileged State 
Stack 

Main Memory 

Maximum Size 

Speed 

Wor d"*size 

Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 

Instruction Set 

Double Precision 
Byte Manipulation 
Bit Manipulation 
Floating Point 
Math/Trig Functions 
Negation 

Arithmetic Complement 
Stack Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging Hardware 



ONIVAC 
MIL-E-16400 
74"Hx18"Dx22"W 
700 lbs. 
1,675 watts 

30-bits 

2 (accumulators) 

1 . 8 usee 
8.8 usee 
15.0 usee 
No 

2nd Generation/Discrete 

Yes 

No 



32K-words 

1.0 usee 

32-bits 

Yes 

Yes 

Magnetic Core 
No 



Yes 
Yes 
No 

Hardware Implemented 
Software Implemented 
One's Complement 
One's Complement 
No 



32K-words 

Multi-level 

7 Index Registers 

No 
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I/O Controller 

No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 

Maintenance/Control Panel 
Location 

Multi-register displays 

Initial Program Load 

Reliability & Maintainability 
MTBF 
MTTR 

Diagnostic Programs 

Modular Building Blocks 

Support Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug Routines 
Operating Systems 
Real-Time 05 

Interrupts 

Priority Structure 
Nesting Capability 



16 

Parallel 

Unknown 

Yes 



Front of Cabinet 
Yes 

Software 



2000 hours 
30 minutes 
Firmware/Software 

Yes 



Yes 

Unknown 
Yes 

Unknown 
Unknown 
Unknown 
Unknown 
Unknown 



Yes 

Four-one per class 
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APPENDIX F 
AN/UYK-12 (V) SYSTEM DESCRIPTION 



Manufacturer 

Construction Standard 

Maximum Physical Dimensions 

Maximum Height 

Maximum Power Consumption 

Architecture 

Word Size 

No. of Registers 

Inst. Execution Time 

Add/Sub/Load 

Multiply 

Divide 
Mic reprogrammable 
Technology 
Privileged State 
Stack 

Main Memory 

Maximum Size 

Speed 

Word-size 

Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 

Instruction Set 

Double Precision 
Byte Manipulation 
Bit Manipulation 
Floating Point 
Math/Trig Functions 
Negation 

Arithmetic Complement 
Stack Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging Hardware 



Rolm Corporation 
MIL-E-5400 
7.6"Hx10. 1"Dx12.5»W 
60 lbs. 
275 watts 



16-bits 

4 (accumulators) 

5.9 usee 
9.7 usee 
9.7 usee 
No 

3rd Generation/MSI 

No 

No 



4K expandable to 32K 

1.0 usee 

1 6-bits 

No 

No 

Magnetic Core 
No 



Yes 
Yes 
Yes 

Software Implemented 
Software Implemented 
One's Complement 
Two's Complement 
No 



1,024 words 

Multi-level 

Two accumulators 

Yes 
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I/O Controller 

No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 

Maintenance/Control Panel 
Location 

Multi-register displays 

Initial Program Load 

Reliability 8 Maintainability 
MTBF 
MTTR 

Diagnostic Programs 

Modular Building Blocks 

Support Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug Routines 
Operating Systems 
Real-Time OS 

Interrupts 

Priority Structure 
Nesting Capability 



61 devices on I/O bus 
Ser/Par 

60 OK- words/sec 
Yes 



Attached or Remote 
No 



Firmware 



11 r 000 hours 
28.6 minutes 
Software 

For memory & I/O 



Yes 

FORTRAN/BASIC/ ALGOL 

Yes 

Yes 

Yes 

Yes 

Batch/Disk 
Disk 



Yes 
Yes 
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APPENDIX G 



DESCRIPTION OF SYSTEM SOFTWARE 

Level Operat ing System 

* Equipment Configuration 

■ ONIVAC 1108 hosted 

* System Routines 

■ AN/UYK-20 Simulator 

■ Macro-Assembler 

■ System Generator 

■ FORTRAN Cross-Compiler 

■ CMS-2M Cross-Compiler 

■ Transfer Utilities 

* Written in FORTRAN IV except for the macro-assembler 
which is written in UNIVAC 1108 assembly language. 

Level I Op erati ng System 

* Equipment Configuration 

■ AN/UYK-20 (V) hosted (a minimum of 2HK-words of 
memory required) 

■ Paper Tape Reader/Punch (required) 

■ Keyboard/Printer (required) 

■ Op to four Magnetic Tape Units (optional) 

■ Line Printer (optional) 

■ Card Reader/Punch (optional) 

* System Routines 

■ Core-Resident Routines (interactive system 
ccntroller, I/O controller) 
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■ Text Editor (edits source code) 

■ Linking-Loader Subsystem (loads relocatable 
object code into memory) 

■ Debug Utility System (memory inspect and change, 
absolute core dump or load, absolute correction 
load, snapshot dump, memory search and constant 
storage) 

■ System Tape Generator 

■ Basic Assembler (generates relocatable object 
code - no macro capability) 

* Written in FORTRAN IV 

Level II Operating Sys tem 

* Equipment Configuration 

■ AN/DIK-20(V) hosted (minimum 65K-words of core 
memory required) 

■ Keyboard/Printer (required) 

■ Card Reader/Punch (required) 

■ Four Magnetic Tape Units (required) 

* System Routines 

■ Core-Resident Routines (system controller, I/O 
controller, batch monitor) 

■ ULTRA-16 Macro-Assembler (generates relocatable 
object code) 

■ CMS-2M Compiler 

a FORTRAN IV Compiler 

■ Linking Loader (loads relocatable object code) 

■ Debug Utilities (memory inspect and change, 
memory dump, absolute core dump or load, absolute 
correction load, snap-shot dump, memory search, 
and constant storage) 

■ Conversion Subroutines (ASCII decimal integer to 
binary integer and vv., ASCII characters to field 
data characters and vv., ASCII octal to binary 
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integer and vv.) 

■ General Utilities (transfer data from one 
peripheral device to another) 

■ Librarian (edit • and update user source code, 
object code and absolute code) 

■ System Tape Generator 

■ Disk File Manager 



gMS-2fl Compiler 

* CMS-2M language is a subset of CMS-2, the standard 
Navy high-level language for tactical applications. 

* Produces relocatable object code for the AN/UYK-20 
computer. 

* Equipment Configuration 

■ Host Computer 

■ Card Reader/Punch 

■ Line Printer 

■ Four Magnetic Tape Units 

* Host Computers 

■ AN/UYK-20(V) with Level II Operating System 

■ UNIVAC 1108 

■ IBM 360/370 

■ CDC 6600/6700 

* Incorporates capabilities for both scientific 
calculation and data management. 

* Uses familiar English words and algebraic expressions 
to define and describe logical operations and data 
manipulations. 

* Components 

• Lexical Analyser - prepares source code input for 
translation 

■ Syntax Analyser - translates source code into 
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intermediate language and generates error 
messages. 

■ Direct Code Processor - translates direct code 
into intermediate language 

■ Code Generator - translates intermediate language 
code into relocatable object code 

■ Output Editor - produces hardcopy listings 



Machine Independent System Generator 

* Produces system tapes for AN/UYK-20(V) from object 
files produced on host machines 

* Host Machines 

• UNIVAC 1108 
■ CDC 6600/6700 



SDSX-20 Real -Tim e Executive 

* Peripheral suite as specified by the user 

* Building block modules provide basic computer program 
management functions upon which the user builds his 
operational programs 

■ Initialization Routines 

■ Scheduling Routines 

■ Interrupt Management Routines 

■ I/O Management Routines 

■ Error Management Routines 



CMS-2Y (2 01 Compiler 

* AN/UYK-7 Computer with SHARE/7 Operating System 

* Components 

■ OYK-20 Code Generator 

■ ULTRA/16 Assembler 
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■ UYK-7 hosted Loader 

■ UYK-20 Simulator/Debug 

* Features 

■ Interfaces with CMS-2Y 
code editing 

■ Extensive Optimization 

■ Produces side-by-side 
listings 



Tool 



(7) Librarian for source 



source code/object coda 
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APPENDIX H 
AN/OYK-20(V) DPS DESCRIPTION 



Manufacturer 

Construction Standard 

Maximum Physical Dimensions 

Maximum Weight 

Maximum Power Consumption 

Architecture 

Word Size 

No. of Registers 

Inst, Execution Time 

Add/Sub/Load 

Multiply 

Divide 
Micro programmable 
Technology 
privileged State 
Stack 

Main Memory 

Maximum Size 

Speed 

Word-size 

Memory Parity Checking 
Memory Write Protect 
Technology 
Multiporf ed 

Instruction Set 

Double Precision 
Byte Manipulation 
Bit Manipulation 
Floating Point 
Math/Trig Functions 
Negation 

Arithmetic Complement 
Stack Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging Hardware 



ONIVAC 
MIL-E-16400 
18.6»Hx24. 0"Dx17.5"W 
185 lbs. 
900 watts 



16-bits 

16 or 32 (general) 

0.75 usee 
3.8 usee 
6.8 usee 

Yes (512 word growth) 
3rd generation/MSI 
No 
No 



65K-words 

0.75 usee effective 

16-bits 

No 

No 

Magnetic Core RAM 
Two (CP/IOC and DMA) 



Yes 

Load/Index/Store/Com pare 

Limited 

Yes 

Yes 

One's and Two's Complement 

Two's Complement 

No 



65K-words 

Multi-level 

All general registers 

64 page address registers 
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I/O Controller 

No. of Channels 
Types of Channels 
Maximum Data Bate 
Processor Independent 

Maintenance/Control Panel 
Location 

Multi-register displays 

Initial Program Load 

Reliability & Maintainability 
MTBF 
MTTR 

Diagnostic Programs 

Modular Building Blocks 

Support Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug Routines 
Operating Systems 
Real-Time OS 

Interrupts 

Priority structure 
Nesting Capability 



16 full duplex 
Serial/Par a llel/DMA 
190K-word per sec 
Yes 



Inside front cover 
No 

192-word Read-Only-Memory 



1500 demonstrated 
15 minutes specified 
Firmware/Software 

Yes 



ULTRA/16, MACRO-20 

FORTRAN, CMS-2M 

Yes 

Yes 

Yes 

Yes 

Levels 0, I, II 
SDEX-20 



Yes-three classes 
Limited-one per class 
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APPENDIX I 



BASIC AN/UYK-20 HARDWARE CONFIGURATION AND OPTIONS 

Basic Configu rati on 

* Microprogrammed Processor 

* Input/Output Controller 

* 16 General Registers 

* Bootstrap ROM - two programs for channels and 
peripheral devices selected by the user 

* 8K-words of Core Memory 

* Power Supply as specified by the user: 

■ Single phase, 115 volts, 60 or 400 hertz 

■ Three phase delta, 115 volts, 60 or 400 hertz 
• Three phase wye, 208 volts, 60 or 400 hertz 

* Four Input/Output Channels (one group) as specified 
by the user: 

a MIL-STD-188C Synchronous (0 to 9600 baud) 
m MIL-STD-188C Asynchronous (four rates of 75, 150, 
300, 600, 1200, or 2400 baud) 

■ RS-232C Synchronous (0 to 9600 baud) 

■ RS-232C Asynchronous (four rates of 75, 150, 300, 
600, 1200, or 2400 baud) 

■ NTDS Slow, Fast, and ANEW in a normal or 
intercomputer mode 

Options Available 

* 8K-word Memory Modules (up to 65K-words) 
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* Additional 16 Gensral Registers 

* Direct Memory Access (DMA) capability 

* MATHPAC Modules 

* Microgrowth Card 

* Special Tools Kit 

* Spare Parts Kit (one year supply) 

* Different Bootstrap Cards 

* Dp to 16 I/O channels in four channel groups - 
options as specified above plus: 

■ NTDS Serial (32-bit) 

■ Dual Channel NTDS (32-bit) 

* Engineering Services 

* Training Courses 
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ROLM 



APPENDIX J 
1602 SYSTEM DESCRIPTION 



Manufacturer 

Construction Standard 

Maximum Physical Dimensions 

Maximum Height 

Maximum Power Consumption 

Architecture 

Word Size 

No. of Registers 

Inst. Execution Time 

Add/Sub/Load 

Multiply 

Divide 
Microprogrammable 
Tec hnolcgy 
Privileged State 
Stack 

Main Memory 

Maximum Size 

Speed 

Wor d*~s iz e 

Memory Parity Checking 
Memory Write Protect 
Technology 
Multipomed 

Instruction Set 

Double Precision 
Byte Manipulation 
Bit Manipulation 
Floating Point 
Math/Trig Functions 
Negation 

Arithmetic Complement 
Stack Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging Hardware 



Rolm Corporation 
MIL-E-5400/16400 
7.6"Hx10. 1»Dx12.5"W 
100 lbs. 
350 watts 



1 6-bits 

4 (accumulators) 

1.0 usee 

5.3 usee 

9 4 use c 

Yes (3.5K-words growth) 

3rd generation/MSI/LSI 
No 
Yes 



65K-words 

1.0 usee 

16-bits 

No 

No 

Core or Semiconductor 
Two (CP/DMA) 



Yes 
No 
Yes 
Yes 

Firmware 
Two's Complement 
Two's Complement 
Yes- 



1,024 words 

Multi-level 

Two accumulators 

Yes 
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I/O Controller 

No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 

Maintenance/Control Panel 
Location 

Multi-register displays 

Initial Program Load 

Reliability S Maintainability 
MTBF 
MTTR 

Diagnostic Programs 

Modular Building Blocks 

Support Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug Routines 
Operating Systems 
Real-Time OS 

Interrupts 

Priority Structure 
Nesting Capability 



61 devices on I/O bus 
Serial/Parallel 
1 , OOOK-words/sec 
DMA only 



Attached or Remote 
No 

Firmware 



11,000 hours 
28.6 minutes 
Firmware/Software 

Yes 



Self-hosted and cross 

BASIC/ALGOL/FORTRAN 

Yes 

Yes 

Yes 

Yes 

Disk-based 
Yes 



Yes 
Yes 
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HP2100A 



APPENDIX K 

SYSTEM DESCRIPTION 



Manufacturer 

Construction Standard 

Maximum Physical Dimensions 

Maximum Weight 

Maximum Power Consumption 

Architecture 

Word Size 

No. of Registers 

Inst. Execution Time 

Add/Sub/Load 

Multiply 

Divide 
Microprogrammable 
Technology 
Privileged State 
Stack 

Main Memory 

Maximum Size 

Speed 

Word-size 

Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 

Instruction Set 

Double Precision 
Byte Manipulation 
Bit Manipulation 
Floating Point 
Math/Trig Functions 
Negation 

Arithmetic Complement 
Stack Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging Hardware 



Hewlett Packard 
Commercial 
12.3»Hx26. 0"Dx16.8»W 
111 lbs. 
800 watts 

16-bits 

Two (accumulators) 

1.96 usee 
10.7 usee 
16.7 usee 

Yes (Writable Control Store) 

MSI/LSI 

No 

No 



32K-words 
0.98 usee 
17-bit 

Yes 
Yes 

Folded Planar Core 
Three (CP/DMA- 1/DMA- 2) 



Load/Store only 

No 

Yes 

Yes 

No 

One's and Two's Complement 

Two's Complement 

No 



2,048 words 
M ulti-level 
No 
No 
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I/O Controller 

No. of Channels 
Types of Channels 
Maximum Data Bate 
Processor Independent 

Maintenance/Control Panel 
Location 

Multi-register displays 

Initial Program Load 

Reliability & Maintainability 
MTBF 
MTTR 

Diagnostic Programs 

Modular Building Blocks 

Support Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug Routines 
Operating Systems 
Real-Time OS 

Interrupts 

Priority Structure 
Nesting Capability 



14 

Serial/Parallel 
1 , OOOK-words/sec 
DMA only 



Front of chassis 
No 

Firmware 



Unknown 
Unknown 
Software 

Yes 



Yes 

FORTRAN/ ALGOL/BASIC 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 



None 
None 
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APPENDIX L 
DEC PDP-11/45 SYSTEM DESCRIPTION 



Manufacturer 

Construction Standard 

Maximum Physical Dimensions 

Maximum Weight 

Maximum Power Consumption 

Architecture 

Word Size 

No. of Registers 

Inst. Execution Time 

Add/Sub/Load 

Multiply 

Divide 
Microprcgrammable 
Technology 
Privileged State 
Stack 

Main Memory 

Maximum Size 

Speed 

Word-size 

Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 

Instruction Set 

Double Precision 
Byte Manipulation 
Bit Manipulation 
Floating Point 
Math/Trig Functions 
Negation 

Arithmetic Complement 
Stack Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging Hardware 



Digital Equipment Corporation 
Commercial 

71.5"Hx30.0"Dx21.7»W 
300 lbs. 
2,300 watts 



16-bit (18-bit addresses) 
16 (general) 

0.3 usee 
3.3 usee 
7.5 usee 
No 

MSI/LSI 

Two - Kernal S Supervisor 
Yes 



128K- words 

0.3 to 0.98 usee 

16-bit (18-bit for parity) 

Yes 

Yes 

Cor e/MOS/Bi polar 

Single - ONIBUS structure 



Yes 
Yes 
Yes 
Yes 

Software 

One's or Two's Complement 

Two's Complement 

Yes 



256K-bytes 
Yes 

All general registers 
Yes 
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I/O Controller 

No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 

Maintenance/Control Panel 
Location 

Multi-register displays 

Initial Program Load 

Reliability 8 Maintainability 
MTBF 
MTTR 

Diagnostic Programs 

Modular Building Blocks 

Support Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug Routines 
Operating Systems 
Real-Time OS 

Interrupts 

Priority Structure 
Nesting Capability 



Multiplexed UNIBUS 
Serial/Parallel 
2, 500K-vords/sec 
Yes 



Front of chassis 
Yes 



Software 



Unknown 
Unknown 
Software 

Yes 



Yes 

BASIC/FORTR AN/C 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 



Yes 
Yes 
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VARIAN- 



APPENDIX M 
73 SYSTEM DESCRIPTION 



Manufacturer 

Construction Standard 

Maximum Physical Dimensions 

Maximum Height 

Maximum Power Consumption 

Architecture 

Word Size 

No. of Registers 

Inst. Execution Time 

Add/Sub/Load 

Multiply 

Divide 
Microprogrammable 
Technology 
Privileged State 
Stack 

Main Memory 

Maximum Size 

Speed 

Word-size 

Memory Parity Checking 
Memory Write Protect 
Technology 
Multiported 

Instruction Set 

Double Precision 
Byte Manipulation 
Bit Manipulation 
Floating Point 
Math/Trig Functions 
Negation 

Arithmetic Complement 
Stack Manipulation 

Addressing 
Direct 
Indirection 
Indexing 
Paging Hardware 



Varian Data Machines 
Commercial 
14"Hx20.5"Dx19"W 
120 lbs. 
900 watts 



16-bit 

16 (general) 

0.66 usee (MOS) 

4.95 usee (MOS 

5.61 usee (MOS) 

Yes (Writable Control Store) 

MSI/LSI 

No 

No 



usee (Core) 



262K-words 

. 33 usee (MOS) /.66 

16-bit 

Yes 

Yes 

MOS/Core 
Two (CP/DMA) 



Yes 

No 

No 

Software 
Software 

One's or Two's Complement 

Two's Complement 

No 



2K-words 

Multi-level 

Yes 

Yes 
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I/O Controller 

No. of Channels 
Types of Channels 
Maximum Data Rate 
Processor Independent 

Maintenance/Control Panel 
Location 

Multi-register displays 

Initial Program Load 

Reliability S Maintainability 
MTBF 
MTTR 

Diagnostic Programs 

Modular Building Blocks 

Support Software 
Assemblers 
Compilers 
Loader 
Editor 
Librarian 
Debug Routines 
Operating Systems 
Real-Time OS 

Interrupts 

Priority Structure 
Nesting Capability 



Multiplexed I/O Bus 
Serial/Parallel 
3, 030K-words/sec 
DMA only 



Front of chassis 
No 



Firmware 



Unknown 
Unknown 
Software 

Yes 



Yes 

BASIC/FORTRAN/RPG 

Yes 

Yes 

Yes 

Yes 

Yes 

Yes 



Yes 
No 
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